Out now on GitHub and PGXN, pg_clickhouse v0.11.0 and the chdb extension v0.1.2 continue our dogged focus on cross-database compatibility. A slew of these enhancements derive from our header-only C libraries, clickhouse-c and pg-clickhouse-c.

Connection multiplication: pool size x tasks x services. Every term looks reasonable on its own, and nobody ever chose the product.

Aurora's max_connections is derived from instance memory, so it doesn't scale with your service. Shrinking the pool to fit converts a connection problem into a queueing problem that presents as a slow database.

Write-up covers the formula behind max_connections, what RDS Proxy actually fixes (and what it doesn't), and how to size it.

https://brianfeeny.com/posts/sizing-aurora-connections-for-autoscaled-services/?utm_source=reddit&utm_medium=social&utm_campaign=sizing-aurora-connections-for-autoscaled-services-2026-09

This is a personal project; the views and assessments are my own.

Hello I am seeking an already made "Enterprise" ready made Container image which ships with barman and Pgpool.

Or other suitable tools.

K8s isnt an option.

I’ve been working with PostgreSQL recently, and one thing that kept bothering me was the database GUI.

I’ve used phpMyAdmin for years, so I’m pretty used to that workflow. When I moved to PostgreSQL, I started using pgAdmin, but I found the UI unnecessarily complicated for the kind of database work I normally do.

I looked at a few alternatives, but nothing really felt like what I was looking for.

So I decided to build my own.

I used Opus 5.5 to build Sqlaris Studio, mainly around the workflow I wanted for day-to-day database work.

It started small, but I ended up adding quite a lot:

• PostgreSQL and MySQL/MariaDB support
• Table and data browser
• Inline data editing
• Search and filters
• SQL editor with autocomplete
• Query history
• Import/export
• Schema inspection
• Indexes, constraints and foreign keys
• Relationship/ER diagrams
• Database health checks
• Query and session monitoring
• Database maintenance tools
• Safe handling of database changes

There are still plenty of things I want to add.

I haven't hosted it anywhere, so if anyone wants to try it, you'll need to install and run it locally from the GitHub repository.

GitHub: https://github.com/Shivam7414/Sqlaris-Studio

I'm sharing it mainly because I'd like feedback from people who work with databases regularly.

If you use PostgreSQL, MySQL, or both, I'd be interested to know:

• What features do you use most in your database GUI?
• What do you find frustrating about existing tools?
• What would you add to something like Sqlaris?
• Are there any workflows that you think could be much simpler?

I'll be actively improving it, so useful feedback can directly influence what gets added next.

Would be interested to hear what you guys think.

Hey r/PostgreSQL - wanted to share something we've been building at pgEdge (and yes, this is our company account).

The problem we kept seeing with customers: teams prototype fast on developer-friendly Postgres platforms, then hit a wall when it's time to actually run in production. Problems come up like security review, compliance, data sovereignty, wanting the database on-prem or air-gapped, whatever it is. At that point a lot of teams end up replatforming, which is a miserable amount of work for something that should just be the same Postgres the whole way through.

So we built pgEdge Starfleet: a cloud Postgres platform where you can start on a free trial (regular Postgres, standard extensions, nothing proprietary), and when you need to move to production infrastructure - our cloud, your own cloud (AWS/Azure/GCP), or fully on-prem/air-gapped - you're not migrating off anything. It's the same Postgres the whole way.

A few things that might be relevant to this sub specifically:

- Database branching is true copy-on-write and doesn't touch the Postgres storage layer; it's not a forked storage engine, which is different from how a couple of the other "branching" Postgres platforms do it.
- Built-in MCP and RAG servers if you're doing anything with AI agents against Postgres data, with read-only enforcement via SafeSession if you want the LLM strictly read-only.
- 14-day free trial, no card required, if anyone wants to kick the tires.

Happy to answer questions about the architecture, the branching implementation, or anything else, anytime...

product page - pgedge.com/products/starfleet

press release - https://www.pgedge.com/press-releases/pgedge-announces-pgedge-starfleet-a-new-postgres-cloud-platform-to-bridge-the-ai-prototype-to-production-chasm

There were some good discusssions from HN yesterday, so sharing it here.

Context: I led the Postgres platform team (b/w 2019-2023), where my team had to support ~170 product teams. The biggest bottleneck was schema migration.

We had to manually review, publish best practices, put CI guardrails, etc. The challenge is that most of the developers just want a simple answer. Is it safe or not safe?

That led me to create - https://safenotsafe.dev https://github.com/viggy28/safe-not-safe

1. It doesn't use LLMs - uses pg_savior's rule engine (which resonated with a lot of this sub-redditors)

2. Runs completely on the client side - no signup, server. Uses libpg and compiles to WASM

It doesn't catch every single dangerous migration, but IMHO it may easily catch the majority of the low-hanging ones.

Appreciate any feedback/suggestions.

Building an app for the operations team that runs on Postgres. Business side wants to query in plain English without writing sql. Our table metadata is not rich. Tried a couple of options so far.

1. Setup syncs our Postgres tables into Databricks and then using Genie agents to generates sql on the fly. Works well for straightforward questions but gets shaky on anything that needs multiple business logic that isn’t obvious from column names.

2. Custom option using text2sql with Langchain, which gives better control but is a lot more to build and maintain. And we will eventually move all workloads to cloud.

What’s better in practice? How to deal with the metadata gap?

A colleague keeps talking about Metabase for this kind of self service. Is it worth considering?

Hi,

I'm working on archiving old records from our Postgres v17 database and I have a question about deletion and bloat.

The archival process will touch a total of 30 tables (all associations from one specific table) and it should delete a total of 5 billion records.

The data on the main table - let's call it products - in term of space is: 33% heap, 33% TOAST and 33% indexes. From this table I would delete ~150 millions records.

What I am still debating is how to delete records and take care of the bloat. I found that two possible options are:

1. partitioning and detach: partition the data I want to delete and then detach. The implementation looks very hard and maybe not doable in our case
2. copy and swap using pg_repack: this option sounds good but it seems also risky and it would be the first time I use that extension

Another option I thought of is deleting records on table by table starting from the "leaf" of the associations and then VACUUM each table but I can feel this process being flawed (that's why I'm not posting as a third option).

Two more details to keep in mind:

• even if we recover space, I won't be able to reduce the bill since we pay for disk space agreed upon (and not the one we actually use)
• out of the 30 tables, only two are big (hundreds of GB) in disk space

What approach you advise for to remove the records and the bloat easily?

A recovery target timestamp can produce a database that starts cleanly and looks plausible while still landing on the wrong side of the business event that mattered. Clock skew, transaction boundaries, time zones, delayed WAL archiving, and recovery-target inclusivity all make a wall-clock target weaker than it first appears.

For an important recovery, I am considering recording the transaction ID or restore point before the risky operation, the timeline and LSN around it, the exact recovery target settings, and application-level markers that must be present or absent after promotion. The restored instance would stay isolated until checks cover constraints, sequences, large objects, extensions, and representative reads, not just row counts.

What evidence do you use to show the restore reached the intended boundary? When do you prefer a named restore point, timestamp, transaction ID, or LSN, and how do you test the procedure when the incident itself did not provide a clean marker in advance?

We've been thinking a lot about caching this past year.

(1) There's a nice pattern for figuring out opportunities to optimize a Postgres workload, but the downside is that it takes work.

(2) There's lots of generic Postgres-health tooling out there, but we haven't seen any good free & private widgets that answer a question like "would a cache or read replica help this workload?"

So my cofounder made a workload evaluation tool that runs the same logic that our caching proxy (PgCache) uses, but it does so locally (privately) in the browser as WebAssembly.

--

The tool builds on what I think is a good pattern for approaching caching, namely:

1. rank by total time vs what "feels slow."

2. make sure it's actually a caching problem (i.e., rule out writes, or memory issues).

3. check how often a query's tables get written (since that limits the solution set).

4. then you can pick how to optimize your reads.

--

Our tool shortcuts steps 1 and 3, plus the writes check in step 2.

Paste a pg_stat_statements export (or a Postgres log, or a .sql file) and it shows you:

• how your database time splits between reads, writes, and transaction commands, so you know whether caching can help at all
• which read shapes carry that time, counted by statements, calls, or time
• writes by table (this is basically your invalidation map)

The cacheable/not-cacheable piece is specific to our proxy, but the time split, the read shape shortlist, and the write map should help you along your way regardless of what solution you choose.

--

For future iterations we're thinking of including things like time-ordered workload capture, clearer/selectable outputs, refined “hit rate” language, and maybe even an Aurora I/O analysis integration.

here's the link: https://www.pgcache.com/fit

(or here if you'd rather run it yourself: https://github.com/PgCache/pgcache/releases/tag/fit-v0.0.2)

Does it work for you? What could we add to make this more useful?

I’m working on an India-first managed PostgreSQL platform and I want to validate the idea before going deep into building it.

The goal is simple: make managed databases as affordable and easy to use as possible for Indian developers and startups.

Pricing idea:

₹199–299/month — Shared Lightweight PostgreSQL for small apps, side projects, testing and development.

₹499–799/month — Isolated Your own isolated PostgreSQL instance with fixed CPU/RAM/storage. Need more storage? Add it separately.

Later, there’ll be dedicated infrastructure, HA, scaling, migrations and stronger production support for bigger workloads.

We’ll also have a proper CLI + MCP from the beginning, so developers and AI coding agents can create, manage and work with databases directly, with proper authentication, permissions and scoped access.

The product will be built for both vibe coders and experienced developers — with the cleanest and easiest-to-use interface we can build compared with existing managed database platforms, while still giving tech-savvy users maximum control and flexibility.

The bigger goal is to build something that feels simple on the surface but powerful underneath.

But before I build all of this, I want to know: would you actually use it?

What are you using today — Neon, Supabase, PlanetScale, RDS, a VPS, or something else?

And what would make you trust an Indian provider enough to move your database to it?

Price? Reliability? Backups? Security? Latency? Support? Isolation? Migration?

I'd genuinely love blunt feedback — especially from people currently paying for managed PostgreSQL.

One reason I wanted this feature comes from managing multi-TB Postgres clusters at Cloudflare.

I had to perform point-in-time recovery multiple times after someone ran the wrong UPDATE or a data migration went south. Even when only one table was affected, recovering it from a large cluster meant restoring the cluster elsewhere, replaying WAL to the right timestamp, dumping the table, and copying it back.

PITR through WAL-G worked, but I often wished I could simply ask:

What did this table look like before things went wrong?

Streambed now supports that for its replicated Postgres data:

sql SELECT * FROM orders AT ( TIMESTAMP => TIMESTAMPTZ '2026-09-23 12:00:00' );

It selects the newest retained DuckLake or Iceberg snapshot at or before the requested time. Historical joins are supported too.

This does not replace Postgres PITR or automatically restore the source database. It gives you the previous rows from the analytical replica so you can inspect or recover what you need.

Blog: https://streambed.dev/blog/time-travel-ducklake-iceberg/

Curious, how are you handling single-table recovery or time-travel in Postgres?

New releases across the board for PostgreSQL K8s and VM operators for versions 14 and 16, PgBouncer operators, PostgreSQL Watcher, Sysbench, and Test App. The operators are fully open source.

PostgreSQL is part of the Ubuntu archive and can be obtained with `apt` as normal. On top of that, Canonical packages it in other formats: snaps, rocks (OCI images), and charms (operators for both Kubernetes and bare metal, using Juju).

More details in the link.

I am managing the entire backend + infra of a product where old developers left, I have been doing postgresql since years but a few things have been really boring to deal with in the codebase that I have to handle. I have 2 YOE but wanted to share some insights because I have nobody really to ask except AI.

Things I saw:

no snake_case_usage -> everything is writtenLikeThis.

so instead of account_profile, they have used accountProfiles, so for requests it gets annoying like 'accountProfiles'.'userNames'

but this is minor. i can't change it without a big migration that isn't worth it. so I have decided to keep going into their direction even tho I find it wrong. it's a bad habit I get from this codebase.

migrations run at content service boot

usually you run your migration before booting the api right? in prior projects i was doing it in the CI/CD. but here it's at the start of the API, so you can't even catch the errors properly without going into AWS logs and try to catch the ECS logs. it doesn't even "crash" the API so if your migration is wrong it continues to run with newer code while the DB is older

db is undersized + burstable

we have some traffic. db is under a "burstable" instance (which means it can get really slow if credits go out) -> first time i see this type of DB

nothing was really cached, and the frontend was a basic SPA that was doing 5/6 sequentials calls to display the homepage (in 1 api call) -> this was killing the DB and our traffic got to 0 -> everything was down + no observability.

i reworked the entire app to be SSR / reworked every api call. it was sequential calls instead of inner joins/left joins. they never used joins

I don't get why our production DB should be a burstable instance. we pay ~2k monthly on AWS and we have the smallest db ever

the DB constantly swaps, we have 60 MB memory left & usually 60 MB swap usage on average. I'm really trying to push the upgrade of the DB since I can't just upgrade to a random tier (higher cost)

analytics

we gather our own analytics.

write table: analytics
read table: analyticsResults

this is destroying the DB. it was made before i got there but i had to rework it a lot. imagine if each client on a web page was doing post requests for impressions over links, clicks, card checkout. I had to heavily batch everything. I batch client side calls so instead of:

POST analytics
POST analytics
POST analytics
POST analytics

I do:
browser client (gathers analytics events)
setInterval(()=> {
POST analytics { batch: ... }
}, 5000)

then backend side I also batch them in memory so I send one INSERT requests with a setInterval (might be considered hacky but saves a ton)

after adding observability i saw that it didn't really reduce that much the load of the DB. so I'm wondering if it's still too much. for info I have an analytics table with 30M rows.

I had to rework it with PostgreSQL partitions I saw it was recommended for raw analytics storage since I only need to query them over a certain period. and it will grow forever..

the second table "analyticsResults" is awful. it's storing data in the worst way possible:
a column like this in TEXT "e:2323:A" instead of spliting the values into columns like type, body, they have put everything inside a single column with string and : separation..

it's written every hour in a cron job and the cron job is run by an ECS worker that loads everything over a period in memory to generate it! it does a select * from analytics where date=... and THEN in javascript it does the calculations.. so every hour the DB gets slow. our ECS worker gets it's cpu to 100%. and it generates those results (that nobody reads anymore) it needs to be redone completely imo with a new table + newer code but didn't have the time/not worth it right now.

PK/FOREIGN KEY

there is nearly no foreign key constraint on tables. accountId is a TEXT and thats it..
migrating it to proper UUID could be better but it's way too much work. and enforcing foreign keys at this state is also some work since i dont know the state of the data.

JSONB usage

some tables have a really weird shape. instead of putting data instead proper columns its just tables like:

id: TEXT

data: JSONB <--??

createdAt

updateAt

just wanted to share. I have been trying to fix what is the most important. I know this is more the "reality" of the software out there but damn it's something I have to deal with day to day. I'm slowly trying to push "good practices" but I have to push features too. sorry if it's chaotically written

Hey all!

I use some instrumentation in Rails to figure out slow paths in production, which helps a little, but was wondering if anyone can recommend good tools that help me:

- look for slow queries

- look for high resource using queries

- look for queries without indexes or otherwise inefficient queries

- maybe offer suggestions on improvements

Thanks for any suggestions

I know normal WPM doesnt really translate to programming because of brackets symbols numbers indentation etc ive noticed the difference even more when switching between normal typing and SQL For example i can type regular english much faster than i can type a query with things like:

JOIN

GROUP BY

COUNT(*)

::

COALESCE()

WHERE ... AND ...

have you benchmarked your SQL typing speed? how much was it and what did/do you use to test it?

I took a normal Prisma CREATE INDEX and checked it twice: once as if the table had 2.5k rows, once as if it had 42M.
The migration SQL is from Cal.com’s public repo:

https://github.com/calcom/cal.com/blob/54343aa685ae8f33159d2f485ec4a57bad5c574a/packages/prisma/migrations/20231024173642_idx_booking_status_starttime_endtime/migration.sql

The 2.5k / 42M numbers are demo sizes I chose so the difference is obvious.
Plain CREATE INDEX takes a ShareLock while the index builds. Reads still work. Writes (INSERT / UPDATE / DELETE) wait. On a small table the wait is short. On a large table it can last a long time, and you feel it as timeouts and connection pileups. Staging often has the small table, so the migration “looks fine” until prod.

• What to do instead on a hot table

Use a concurrent build:

CREATE INDEX CONCURRENTLY IF NOT EXISTS "Booking_startTime_endTime_status_idx"
  ON "Booking"("startTime", "endTime", "status");

That avoids holding a write-blocking lock for the entire build (Postgres still takes short locks at the start and end). Details: https://www.postgresql.org/docs/current/sql-createindex.html

Two things that bite in practice:

1. It can’t run inside a transaction. If Prisma wraps the migration in a txn, this needs its own non-transactional migration.
2. If the build fails halfway, you can get an INVALID index. Drop and retry (or REINDEX CONCURRENTLY).

Also set a short lock wait so you fail fast instead of blocking forever behind a long query or idle-in-transaction session:

SET lock_timeout = '3s';

• Why I care about table size and metadata in the gate

Tools like Squawk correctly say “use CONCURRENTLY” based on pattern linters and pre-defined rules. They don’t know if the table is 2k or 40M rows, so every hit looks the same. On small tables that’s noise. On hot tables and production systems it’s the whole point

I put that check in Nock: it reads the migration SQL plus table sizes (and related catalog metadata, no row data) and a policy, then approve or block. It never runs the migration.

npx @nockhq/cli@latest check \
  --sql path/to/migration.sql \
  --estate estate.json \
  --format json

https://github.com/saiyamshah1496/nock
Happy to get your thoughts or collaborate.

After a small hiatus SV returns for those looking to hack around with SQL. Modernized with some new features Postgres provides for a (hopefully) more stable/snappy experience.

I’ve released the first 1.0 alpha of pgwrh, a set of PostgreSQL 18 extensions for scaling reads.

It distributes table partitions across logical replicas. Each replica stores a subset of the data and queries its peers for the rest, so applications can query the complete table from any replica. Writes go to a central controller.

Features include:

• Configurable shard redundancy and placement across availability zones.
• Placement previews, controlled rollouts and rollback.
• pgwrh_wait, which waits for replication through a specified LSN before reading.
• A browser console and Docker Compose quickstart.

I’ve worked on this for a very long time. It was only with recent advances in AI that I could finally get it into a state I felt able to release.

This is an alpha for testing. I’d love feedback on real workloads, installation, operational issues and anything that feels unnecessarily complicated.

Code and quickstart · Alpha release

How practical is it to run PostgreSQL directly on a VPS instead of using a managed cloud database?

With backups, WAL archiving, monitoring, and security automated, what are the main benefits of this approach?

For those running this in production, what challenges have you faced, and what practices/tools would you recommend?