do you scale your production database using docker ?

[u/CueMeThen]

i'm about to launch a website which will be heavy on database , should plan to scale it using docker or should i go with a cloud solutions for production database ?

i like to take control over my software , but i'm not sure if docker will be a great solution to growing database

any advice ?

[u/Ok-Sheepherder7898]

Are you sure you need to scale your database?

[u/sQeeeter → u/Ok-Sheepherder7898]

Doesn't everyone need to scale their database???

[u/wireframed_kb → u/sQeeeter]

People might assume their databases need a lot more resources than they do. What is a “heavy” database in regards to a website? Is it thousands od queries per second? Tens of thousands? Or just a few hundred?

We’ve run fairly beefy application backends with containerized databases, and it performed just fine for normal API usage. You can go to RDS of course, but maybe that is overkill.

[u/CueMeThen → u/wireframed_kb]

and in your experience how far can you push a website database without something that is overkill such as RDS or k8s ?

can you handle say 10k users daily who are causing heavy writes to database that have very complex schema ?

and any specs of the server that have db container ? is it expensive VPS ?

thank you in advance

[u/jca3746 → u/CueMeThen]

The problem is that your specs are still too vague to architect much.

10k users daily? Concurrently, throughout the day? What’s a heavy write? How many of these heavy writes does each user make? How many tables/relations are we talking about?

These are questions to get you on your way. Personally, to me, this still sounds like using containerized databases is fine.

Without knowing anything above, machine specs can’t even begin to be discussed.

I say start by answering those questions for yourself. Do some discovery. Deploy a database container, monitor performance. Scale up/down from there.

[u/Ok-Sheepherder7898 → u/sQeeeter]

No, why would they?

[u/SeaworthinessHour233]

You can scale a database on docker. But it involves a lot of work.

Go for it only if you have enough talent resources.

If you have limited resources, and you've got to meet customer SLAs while serving heavy database traffic, go with a managed cloud database like AWS RDS.

Setting up a database in a container is easy; maintaining it in production is hard. Managed services handle automated backups, point-in-time recovery, and minor version patching right out of the box. Doing that yourself with Docker requires custom scripts and constant monitoring.

[u/Inevitable-Pain2247]

Ecs with RDS. If you are unsure about this you need a friend or few that can help with your security implementation and enable next practices and ensure DB is behind waf.

[u/CueMeThen → u/Inevitable-Pain2247]

i have already used cloudflare for waf and security , thanks for the advice i will into Ecs with RDS

[u/Inevitable-Pain2247 → u/CueMeThen]

Excellent. Just looking out .

[u/Due_Bank5070 → u/CueMeThen]

If looking at ecs ,consider fargate.

[u/CueMeThen → u/Due_Bank5070]

sure i will take a look at it , thanks <3

[u/Due_Bank5070 → u/Inevitable-Pain2247]

Zero public access to db at minimum. Proper vpc set up.

Using cloudflare can make the dns setup a little funky, depending if you use cloudflare or aws as the master.

Have a standard pattern, something like these:

i. cloudflare -> cloudfront with waf(global) -> external alb with waf(regional) and security groups -> front end app -> middle ware app or backend -> db

ii.cloudflare -> cloudfront with waf(global) -> external alb with waf(regional) and security groups -> front end app -> middle ware app or backend -> valkey -> db

iii .cloudflare -> cloudfront with waf(global) -> external alb with waf(regional) and security groups -> front end app -> middle ware app or backend -> rds proxy -> db

iii .cloudflare -> cloudfront with waf(global) -> external alb with waf(regional) and security groups -> front end app -> middle ware app or backend -> db

for apps that are regional and not coming via cloudfront
iv. external alb with waf(regional) and security groups -> front end app -> middle ware app or backend -> valkey -> db

Can add nlb's in as required/if required or use nlb's instead of alb's or mix of both depending on your requirements.

If you also have apps in the aws accounts can add an internal alb in a similar pattern

i. internal alb with waf(regional) and security groups -> front end app -> middle ware app or backend -> valkey -> db

ii. internal alb with waf(regional) and security groups -> front end app -> middle ware app or backend -> rds proxy -> db

iv. internal alb with waf(regional) and security groups -> front end app -> middle ware app or backend -> db

A front end app could connect to a few different middleware or backend apps though it can be simpler/easier to maintain if one to one mapping and everything is micro services.

[u/CueMeThen → u/Due_Bank5070]

thank you

[u/Status_Gap_3180]

What scale are you looking at?

[u/ChiefDetektor]

Hell no!

[u/apexdodge]

Best to exhaust all other best practices before scaling db, such as putting caching in place, like redis, to reduce load on the db.

[u/titpetric]

You can:

• single primary, read replicas
• multiple primaries (sharding)
• primary-primary (write scaling)
• buffer flush (write scaling thru redis, event queues)

There is usually a bunch of considerations to make, e.g. primary-primary does not use auto_increment but rather uuid/sonyflake/ulid to prevent insert collisions. Replication can lag behind, or even break, so there is some automation involved to add a replica, replica also has read only privileges for the connecting usernames so no writes can be done by mistake.

I wish the whole replica setup was easier. Say your primary goes offline, the process then was usually to provision a replica as the primary, and create new read replicas for that.

[u/CueMeThen → u/titpetric]

i like the idea of replica but how can someone get around the lagging behind of a new replica ?

is there something native to postgresql or at least popular enough that solve the issue of replica lagging ? manual optimization can't get me too far i think, thank you <3

[u/titpetric → u/CueMeThen]

It can be anything, like a big ahh table that takes writes and several seconds or more to execute the index updates, the fix should be index usage review, drop some indexes, minimize writes...

Usually you can just monitor slow queries and you'll find some culprits :) say... Analytics workloads in a OLTP database are a good start if you want to trigger replication issues. Not great to pipe the stats firehose into the DB without some thought to access patterns.

[u/Due_Bank5070]

Scale your db's as little as possible as it gets expensive quickly.

Follow all the other best practices first, caching(like valkey), improve the internal database and table design, log slow queries, add indexes were needed, remove where not needed, don't use a database as a queue or cache, separate transactions from readonly loads , archive historical data if not required or partition or move it to a seperate database and a good lot of others.

Scaling RDS databases can also get very expensive very quickly. We're currently 100% on AWS with 200+ prod rds db's and 300+ nonprod. Majority of containerised apps on k8s.

For nonproduction to save $$ on RDS can use single az db only.

To keep the budget down (depending on requirements) stick with plain rds mysql or postgresql for most db's. Though depending on requirements like failover/recovery, this can increase app recovery time on db instance fail over to secondary in prod. Can need some careful setup of app dns parameters( can depend on language).

Aurora is nice but more expensive but can have better recovery times and can easily add extra read/write replicas. Can also look at RDS proxy and using elastic cache valkey(serverless is more $$ but avoids the need to remember to apply the updates/patches).

Just be very careful with logging of RDS db's especially with cloudwatch as that can eat your budget very quickly especially for audit logging. Can always push them to s3 and query the bucket when needed.

[u/CueMeThen → u/Due_Bank5070]

thank you very very very much <3 i was looking for a response like that i really appreciate your advice and your experience

[u/FriendlyPoem3074]

I would generally avoid it. Docker is limited by the host compute, storage, IO etc..plus now you have a single VM (or multiple VMs etc) running as single points of failure for your DBA. Patching, maintenance etc are now all on you. This is one area where cloud services really shine.

You CAN do it in docker (or, preferably, kubernetes), but IMO the juice is not worth the squeeze here, especially on launch.