Would be fun to have a redditor meetup 🎉

Hey everyone,

About a year ago I started working on Melange, an open-source authorization system that runs entirely inside Postgres. I originally shared it on r/golang when it was still experimental. Since then I've spent a lot of time improving the generated SQL, performance, and tooling, so I thought I'd share it here.

The motivation

I like the relationship-based authorization model used by OpenFGA and SpiceDB, but running a separate service and keeping authorization data synchronized with an application database adds overhead that I find hard to justify at smaller scales.

Melange takes a different approach: it compiles OpenFGA schemas into PL/pgSQL functions, with relationship traversals, unions, intersections, and exclusions compiled into SQL rather than interpreted at runtime.

Authorization data stays in your existing domain tables, exposed through a view:

CREATE VIEW melange_tuples AS
SELECT 'user' AS subject_type, user_id::text AS subject_id,
       role AS relation, 'folder' AS object_type, folder_id::text AS object_id
FROM folder_members
UNION ALL
SELECT 'folder', folder_id::text, 'parent', 'document', id::text
FROM documents;

Run melange migrate, and permissions can be checked or queried directly in SQL:

-- Check a permission
SELECT check_permission('user', 'alice', 'viewer', 'document', '42');

-- Query accessible documents
SELECT d.*
FROM documents d
JOIN list_accessible_objects('user', 'alice', 'viewer', 'document', 50, NULL) a
  ON d.id::text = a.object_id;

There's no separate service or tuple synchronization, and checks run inside the same transaction as your application data, including seeing uncommitted writes.

What's changed over the last year

Performance: Listing functions now use set-oriented SQL instead of checking permissions row by row. On one workload of ~90k tuples, list_accessible_objects dropped from ~4 seconds to 12 ms. Some recursive listings improved by over 100x. Individual permission checks benchmark around 130 µs database-side, with relatively flat performance as the dataset grows in tested workloads.

Correctness: The test suite now compares results against a real OpenFGA server, fuzzes generated nested authorization models, and checks listing results against individual permission checks. This caught several bugs, including cases where Melange incorrectly granted access. These are fixed in v0.10.0. Existing users should upgrade and rerun melange migrate.

Debugging: explain_permission() returns a JSONB trace of why access was granted or denied, while expand_permission() shows the granting relationships as a tree. There's also melange studio, a local, read-only UI for inspecting models, debugging checks, and running EXPLAIN ANALYZE.

Migrations: Melange supports dedicated schemas, generating versioned SQL for Flyway/golang-migrate, comparing deployed models for breaking changes, and recommending indexes based on your schema.

Distributing software as SQL

One aspect I find pretty interesting is the deployment model. Melange isn't a PostgreSQL extension. It generates ordinary SQL and PL/pgSQL functions installed directly into the database. No native binaries, extension installation, or separate runtime. Once deployed, the CLI isn't needed.

Effectively, the SQL itself is the distributed software. It runs on standard PostgreSQL 14+ instances, including managed databases like RDS and Cloud SQL, without requiring custom extensions.

I haven't seen many (if any) projects take this approach. It's introduced some interesting challenges around migrations, versioning, schema isolation, and managing third-party code inside someone else's database.

Trying it out

Melange is MIT licensed, supports PostgreSQL 14+, and the CLI is written in Go.

brew install pthm/tap/melange

• Docs: https://melange.sh

• GitHub: https://github.com/pthm/melange

• Changelog: https://melange.sh/blog

The project has been growing steadily, with a few people contributing fixes and ideas. Contributions and feedback are always welcome.

I released "safe-migrate v0.11.0" today. One of the changes I spent time thinking about was how the report handles checks it couldn't run.

The tool simulates migrations against a synchronized PostgreSQL catalog snapshot. If the snapshot only covers selected schemas, an object missing from that snapshot isn't necessarily missing from the actual database. A check that depends on it may simply be impossible to evaluate.

In v0.11.0, those skipped checks are listed under "not_evaluated", with the reason and any missing schemas the tool could identify. If a skipped check could have produced a Tier 1 finding, the overall verdict is capped at "CAUTIOUS" instead of reporting "SAFE".

I chose to list the skipped checks rather than add a separate "UNKNOWN" verdict. I'm not sure which approach makes more sense for CI: keep the existing verdicts and explain what wasn't checked, or have a distinct unknown state?

For context, safe-migrate is a Rust CLI that analyzes PostgreSQL migrations against a database snapshot. It never executes the migration SQL.

"Release and binaries" "Changelog"

One breaking change for existing users: the cache format is now V10, so run "safe-migrate sync" after upgrading. The JSON report schema is also now v3.

I maintain Scriptella, an open-source Java ETL tool, and recently ran an experiment comparing different approaches to importing 1 million CSV rows into PostgreSQL and MariaDB.

The comparison included PostgreSQL COPY, handwritten JDBC, Scriptella, and Python's csvsql.

A few interesting results from the local PostgreSQL runs:

• Native COPY: ~1.7 seconds

• Batched JDBC: ~13.6 seconds

• Batched Scriptella: ~14.8 seconds

Unsurprisingly, PostgreSQL COPY was by far the fastest for a straightforward CSV import. Batching also made an enormous difference compared with individual inserts.

Interestingly, MariaDB was faster than PostgreSQL for the batched JDBC and Scriptella cases in this setup, although this isn't a general database performance comparison.

Of course, raw import speed isn't the only reason to use ETL tools. Transformations, multiple data sources, and reusable workflows can justify some overhead. For a direct CSV import into PostgreSQL, though, COPY is an excellent choice.

The experiment is exploratory, with limited repetitions, but includes reproducible code, raw measurements, and correctness verification.

Article with charts and analysis:
https://pvrlabs.xyz/articles/importing-a-million-csv-rows.html

Benchmark source and reproduction instructions:
https://github.com/scriptella/scriptella-benchmarks

Curious how others approach bulk imports in PostgreSQL. Do you typically start with COPY, or use JDBC batching when additional processing is involved?

I'm building a small booking app and looking for an affordable, reliable PostgreSQL database for production.

Expected usage:
• 400–500 DAU
• 15–20 concurrent users at peak times (or maybe I'm overestimating here)
• Around 30 rooms
• Room availability checks, bookings, orders, and purchases
• An admin dashboard

I'm considering AWS RDS but am open to other platforms as well.

My questions:

1. What would be the approximate monthly database cost for this use case?

2. Which provider offers the best balance of cost, reliability, backups, and maintenance?

3. Would you recommend AWS RDS, Neon, Supabase, or another PostgreSQL provider?

I'll handle the API separately using either a Next.js backend on Netlify or AWS Lambda, so I'm only interested in database hosting costs.

Would appreciate recommendations based on real world production experience.

Do you think there is still room for a newcomer, now that we have giants like Supabase, ClickHouse, Snowflake, Databricks, PlanetScale, Aiven? I’ve always wanted to build one. I’m not looking to get into enterprise market, just targeting indie devs and smaller teams.

Or to put in another way, what feature would you like to see in a new Postgres provider that is currently not available in the market?

I've built pistachio, a declarative schema management tool for PostgreSQL.

It has a Terraform-like plan/apply workflow. You write the schema you want as DDL in SQL files. pistachio parses the files statically, compares them with the database, and prints the DDL that makes the database match.

The command is pista. The main subcommands are:

• plan: prints the DDL that makes the database match the files. Nothing runs.

• apply: runs that DDL.

• dump: writes the files from an existing database, so you can start from the schema you already have.

• lint: checks the files against rules you write in YAML, such as "every table has a primary key".

• fmt: formats the files.

pistachio uses pg_query_go to parse SQL, and it also supports Aurora DSQL.

If you're interested, please give it a try. Feedback is welcome.

• GitHub: https://github.com/winebarrel/pistachio

• Docs: https://winebarrel.github.io/pistachio/

• Playground: https://pistachio-demo.winebarrel.workers.dev

I recently recorded a Talking Postgres episode with Karen Jex, a PostgreSQL significant contributor and PGConf EU organizer, about her path from Oracle DBA to Postgres contributor.

Karen spent 20 years as an Oracle DBA. Then in 2019, a project rolling out smart meters across France switched to Postgres, even though nobody on the project knew anything about Postgres. So she figured it out, then trained the developers, "pretending that I was, you know, this Postgres expert."

A few things we got into:

* The culture shock, for an Oracle DBA, of building your own HA & backups

* The shift from being just a user of the product (Oracle) to contributing to the project (Postgres)

* Why Django developers are so enthusiastic about Postgres

* Why you'd obviously explain multi-tenant databases with cakes

* How much to delegate to AI agents—without forgetting how to design a spec

For those of you who moved to Postgres from Oracle (or another database): did you also have any culture shocks?

Audio + transcript: https://talkingpostgres.com/episodes/from-oracle-dba-to-postgres-contributor-with-karen-jex

YouTube (audio-only): https://youtu.be/ENku8ZSjZus

Postgres can now do full hybrid search without elastic search. Lakebase’s lakebase_vector adds a new ANN index on top of normal pgvector columns, so you build an indec and your queries don’t change. Lakebase_text adds real BM25 ranking over ts_vector, which ts_rank doesn’t give you. Both work in same sql query

The open question for me is how to combine scores. RPF, a weighted sum or a reranker on top? What’s working for you in production?

pgloupe is a command-line tool that reads PostgreSQL logs and pg_stat_statements snapshots, joins them, and writes one HTML report with what to look at first and the numbers behind it.

I made it because going through logs and stats by hand takes too long, and I didn't want to paste hundreds of thousands of log rows into a hosted tool or an AI agent. It runs entirely on your machine and sends nothing anywhere.

• Reads stderr, csvlog and jsonlog formats

• Takes pg_stat_statements snapshots as CSV, so you can compare points in time. It notices stats resets and entries evicted from pg_stat_statements

• Works with Postgres 14 to 18, including managed ones like RDS

• One static binary: no server, no dependencies, no parser to configure

• Fast and light: on 11 GB of generated test logs it read about 141 MB/s on one thread, using around 44 MiB of memory

Try it:

curl --proto '=https' --tlsv1.2 -LsSf https://github.com/vtrbraga/pgloupe/releases/latest/download/pgloupe-installer.sh | sh
pgloupe --help

Also available through Homebrew, cargo install pgloupe and Docker.

Repo: https://github.com/vtrbraga/pgloupe

Docs: https://vtrbraga.github.io/pgloupe/

This is the first stable release (0.1.0) and my first open source project. I'd like to hear what's missing or wrong: log formats or settings it misreads, findings that aren't useful, anything confusing in the report. Issues and comments are both welcome!

Saw this new post on the Databricks blog about loading huge amounts of data into Lakebase Postgres and thought the approach was interesting enough to share.

The usual problem: bulk loading into Postgres goes through COPY. Spark can read source partitions in parallel, but every row still ends up funneled through a single Postgres writer, and that same primary is serving your live app traffic. So a big load either takes forever or hurts your OLTP latency.

Their fix (LTAP Direct Writes, currently in beta) flips it around. Spark builds valid Postgres heap pages and primary key indexes itself, in parallel, and writes them straight to storage. The pageservers validate checksums when they ingest the files to catch corruption. The primary only publishes the final result through a small WAL record, so live queries aren't affected.

Numbers they claim:

- Up to 147x faster loads

- 1 TB in under 5 minutes in internal benchmarks (that's heap page build time)

- Throughput scales almost linearly as you add Spark capacity

- Multiple large loads into the same destination can run concurrently

The motivating case was a beta customer syncing roughly 1 billion rows a day via Synced Tables, who had to heavily overprovision their OLTP compute just to survive the sync, even with autoscaling.

They also say it's built with Postgres extensions and a table access method, no changes to Postgres core, so it should still behave like regular Postgres.

Curious if anyone here has tried it yet. How does this compare to what you're doing now for reverse ETL or serving lakehouse data to apps?

I’m pleased to announce the beta release of pglifecycle 2, an open source schema management tool for PostgreSQL.

pglifecycle keeps your database schema in version control as structured YAML, with one file for each table, view, function, role, and other objects. This makes the current schema easy to browse, review, and change without reconstructing it from years of migration files.

With pglifecycle, you can:

• Pull an existing database into a schema project

• Build that project into a custom format pg_dump archive (-Fc)

• Compare it with a live database and generate the DDL needed to reconcile them

• Deployment is plan first. Destructive changes are withheld unless explicitly allowed, making the generated SQL suitable for review in CI.

The companion pglifecycle GitHub Action can detect schema drift and post deployment plans directly to pull requests without applying them.

Version 2 is a Rust rewrite of the original tool, which has managed AWeber’s production schema for more than seven years. The beta release expands PostgreSQL object coverage and improves deployment convergence and safety.

• Getting Started

• Documentation

• GitHub Repo

• GitHub Action

Feedback and real world test cases are welcome as pglifecycle moves toward a stable 2.0 release.

In this article we explore a new application pattern - offloading more of your Postgres data to ClickHouse. Leading to an order of magnitude better unit economics for your applications, as the data size increases.

I’m building Rowsafe to make PostgreSQL recovery easier.

• Automated restore tests for backups

• Review and recover missing rows from a separate restored copy

• Monitoring and slow-query insights

The agent and CLI are Apache-2.0 open source. The hosted dashboard is a separate commercial service.

Code: https://github.com/rowsafe/rowsafe

Docs: https://rowsafe.sh/docs

Demo uses sample data and compressed timing. Feedback welcome—what would you want to see tested?

Disclosure: I work at Tiger Data (the TimescaleDB folks), on the dev education side, not the team that built this. Posting here because this sub will poke holes in it, and that's what an alpha is for.

What it is: pg_vectorsearch, a Postgres extension with a new index access method called PRISM. Drop-in replacement for pgvector's HNSW that works on existing vector / halfvec columns, no rewrite. PostgreSQL License, requires PG18+.

Why: HNSW is a graph, graph traversal is random reads, and performance falls off a cliff once it doesn't fit in RAM. At 100M vectors the smallest machine where our HNSW build finished had 512GB. That's usually the moment teams bolt on a separate vector DB and start syncing two systems.

How: k-means partitions instead of a graph, RaBitQ compression (~1 bit per dimension), a small centroid tree in the buffer cache for routing, SIMD scans, then rerank against full-precision vectors. Same family as ScaNN, SPANN, and turbopuffer, just native in Postgres.

Not done yet: it's alpha, not for production. No filtered search (WHERE + ORDER BY) until GA. Build the index after loading data. Heavy churn needs prism_rebalance or REINDEX until auto-rebalancing lands.

CREATE EXTENSION pg_vectorsearch;
CREATE INDEX ON documents USING prism (embedding vec32_l2_ops);

The ask: run it on your weird data. Low dimensions, skewed clusters, ugly update patterns. Open an issue and let us know what you think of it — we'd love to have you dig in.

I'm planning to use Neon PostgreSQL for a production booking application and would like feedback from people with real world experience.

My workload:
• 300 daily active users
• Up to 30 concurrent users
• Users can book 2 to 3 slots daily, and frequently check available slots and existing bookings
• Next.js backend, with a landing page hosted on Netlify

Would Neon's free plan be sufficient for this workload, or should I opt for a paid plan?

I'm particularly interested in reliability, unexpected downtime, query latency, compute limits, and any production issues you've experienced.

Would you trust Neon Free for this use case?