[hmokiguess]

Postgres is my favourite thing, but I find it's prohibitively costly when bootstrapping something that is lean and frugal.

I end up with a mixture of serverless storage like DynamoDB, S3, DuckDB on S3, and SQLite.

Am I crazy? How can one have a decent Postgres and not pay at least $100/mo (yes, when I say frugal I mean really frugal ... think solo founder that likes to stay on free tiers haha) -- I am aware of Neon/Supabase, but last time I tried them they ended up becoming a tightly coupled annoying dependency after scale that defeated the cost savings as they grew in costs and we ended up migrating to Aurora / RDS lol

EDIT: I'm aware of the self-hosted path but I find configuring the above things faster/cheaper in terms of my admin hours than the self hosted postgres db. Maybe I just suck at being a DBA or need better education on it, that said, I have AI now so I should give it a chance again as it's been a minute since I created a fresh thing

[faangguyindia]

I run pgautofailover with 2 replicas and 1 monitor, you can run 2 replicas on equal configuration, though i size primary bigger and monitor node is tiny.

You can run this on $10x2 = $20 per month setup for 2 replicas and 1 monitor node for maybe $2-3.

For most other projects i just use sqlite, backup periodically to s3.

some report (coincidentally i was checking health of my small cluster for an app)

Common application queries average under 4 ms:frequent analytics queries: ~0.9–1.4 ms average common inserts: ~0.4–3.4 ms average the slower recurring reporting query: 62 ms average across 53 calls, 308 ms worst case

Query volume is approximately 2.30 million SQL statements/day (~26.6 statements/sec), based on pg_stat_statements over the last 97.3 days. That includes every SQL statement, not just user-facing requests: BEGIN/COMMIT alone account for ~1.05M/day, analytics inserts for ~522K/day, and HA/monitoring checks for ~118K/day.

[hmokiguess]

man this makes me feel I'm doing everything wrong, I really should go learn some proper db hardening

[superze]

How can this comment be true. 4 Ms for analytical queries. Does your db consist of just one int column that tracks ur daily coffee consumption or what? I am calling bs

[ComputerGuru]

It runs easily on a vps at your scale, even the same vps serving your app. That used to mean having a modicum of sysadmin knowhow but it’s straightforward these days, especially if you just use a premade docker file.

[busymom0]

I went with the self host route by putting it on a few years old computer with much better specs than cheap vps. Cloudflare tunnels to make the web server accessible on the internet.

[christophilus]

Nice. How fast is your home internet connection? I’ve thought about putting an old laptop to this use. But I don’t want my day to day internet to suffer if my site gets traffic spikes. And also, I’m nervous about non-ecc ram.

[busymom0]

My internet is very fast for sure (can give more concrete numbers when I am home later) but I don't think you need to worry about it unless you are operating some massive website with huge traffic concurrently.

[ComputerGuru]

Bandwidth is almost never a concern for databases. The right number to worry about instead is latency.

[allthetime]

The $10 VPS that serves your web app can run Postgres just fine. If it can’t? Fire up another $10 VPS. Learn how to tune your configs and network settings and query/cache efficiently.

[edoceo]

Any pointers to network configuration to tune? Some TCP stuff? How much does it matter on that VPS network?

[allthetime]

Yeah mostly just keepalives and timeouts, increasing kernel maximums for connections, using Unix sockets directly instead of tcp, using pgbouncer, etc. as always, depends on use case and monitoring and measuring to determine your needs is good.

[Lukas_Skywalker]

This is a pretty good resource for some basic tuning (mostly buffer sizes and connection count): https://pgtune.leopard.in.ua/

[chasd00]

man, i wouldn't worry about tuning something like TCP until you can reliably prove TCP is the bottle neck in performance. That day will likely never come for most companies.

[frollogaston]

Cheapest Amazon RDS Postgres is like $15/mo if that's cheap enough. If you're doing lots of projects and don't want to pay that for each one, you can CREATE DATABASE for each with separate ACLs.

You mentioned not wanting to spend admin hours fine-tuning a self-hosted instance though. Are you really hitting the DB hard enough for that to matter, but SQLite works fine? Cause I haven't tuned local Postgres in years.

[hmokiguess]

Fair pushback, I think a lot of it is just stigma from not working close to the db layer and relying on these abstractions

I think most of the work I've done just fits in the other storage models and they scale really far really fast at $0 cost

I haven't paid for then ever, similarly, I have a few super tiny apps on Supabase and Neon too that cost me $0

On another project that got traction though, Postgres became better DX than DynamoDB and such, but that traction came with the overhead cost

The "fine-tuning" was setting up things like pgbouncer, restart, vaccuum, query optimizer, etc. Like, the db would always create some amount of work every fortnight. Coming from managed services, especially these serverless ones, they just work and you do nothing so it makes you spoiled.

Different mental model maybe?

On the "hitting the DB hard enough for that to matter but SQLite works fine" -- Absolutely! I have a <10gb SQLite inside a Lambda for some complex queries, and that gets refreshed whenever that data changes (which is not that often).

[frollogaston]

Well it might be relational vs non-relational. And I get that SQLite is relational, but you might not be using it in a relational way.

[munk-a]

Until you need to scale up it's perfectly acceptable to just run postgres on the same instance as the logic that's executing. It's not a great strategy in the long run due to all your eggs being in one basket and the need to configure things like backups manually but it'll save buckets of money compared to going with something prerolled by AWS while the functionality it'd give you wouldn't be noticeable.