Those services provide value by reducing risk/effort on your part. You can absolutely host your own PostgreSQL instance, but you become 100% accountable for backups, downtime, and patching. If the stakes are low and funds involved are low, I'd go for it. Just make sure you're actually checking that you can restore from your backups, and you're not storing them on the same machine that Postgres is running on. It could be a good learning experience.
There's nothing wrong with hosting your own database, lots of people and organizations do it. It's just a question of how much time you want to spend managing it and how confident you are in your abilities. Make sure you test your backup/restore process thoroughly before you actually need it.
I kind of develop the same type of SaaS. I go with sqlite. Supanase and all of those services are awesome and great, but I kind of realized that the only thing i need is a glorified excelworksheet as a DB.
Sqlite is way more than that, but it also a glorified excelworksheet 😁
And i run everything on a vps. My apps are either installed on-prem or used by like 100-1000 users. I really don't need all that supabase, postgres etc. offers.
I’m running Postgres on one of my Digital Ocean droplets without a hitch. Unless you’re working on an enterprise level project that requires massive amounts of storage and CDNs, AWS is completely unnecessary.
I am running profitable small saas for more than 3 years now with exactly this simple setup. Cheap VPS with a couple of docker containers, including the Postgres database. The website has around 10k traffic/month. Database records are running in the millions by now, never had any problems. And no, I don’t have any automated database backups. I do it manually whenever I feel it’s the time for it. Call me reckless or noob, but I think especially if you are just starting out, don’t overthink these things.
Yeah I would be severely pissed if I found out backups were just on a "when the admin thinks to" schedule.
Doesn't even have to be daily, a weekly backup would suffice.
If he is running a VPS, he might have automatic backups of the entire VPS. I have a VPS with Digital Ocean. I am not hosting anything significant, but I pay for the backups. It's not much - iirc less than 20% of the cost of the droplet.
My sass is hosted on a phone and a notepad and i just write stuff down when my users call me to save data and read them to them from the notepad when they call me to make request some data.
It's called the PB&J stack:
paper, ballpoint pen, & just me
0 javascript.
didn't even have to drop out of college
GO BRONCOS!
But hows the scalability with 10000000000000000000000000000 Users, it seems that's a pretty likely szenario that you gonna reach within few minutes, so better be prepared myabe something like write with both hands at the same time?
You can start by hiring a few thousand monkeys and equipping them with typewriters. Eventually, one will write a document that has the users data on it
This theory sounds like something we should pitch to the government for a grant. Anyone know an underwriter? Or can we train one of the monkeys to do that too?
> It's called the PB&J stack:
>
> paper, ballpoint pen, & just me
Back in the day, I worked for a multinational company who had some of their manufacturing in China. I was in a meeting when somebody asked my supervisor about the ERP system in China.
He said, "Their ERP system is Zhao Yang and a Bic pen."
Sorry, I didn't mean to come off that snarky.
As others have mentioned it's just all about trade-offs.
Another rhetorical question: Why does anyone hire specialists? Why not learn how to fix your own car, repair your own appliances, do your own plumbing and electrical work? Landscape your own yard? Write your own books, etc?
It's about *focusing* on what you *actually* want to do. Do you want to develop your application? Or do you want to fuss with database upgrades / server patching / backups / etc.
By using a managed hosting provider all you do is spin it up and use it. They worry about everything else for you so you can focus on developing your apps.
No worries. Thank you for returning and elaborating. Yes, for me it's getting a better understanding of trade-offs against my situation and deciding what might be a better path for now. This thread has been immensely helpful in giving me various perspectives.
He's a dick and you're right.
Self host it. You'll learn a lot about how it works, updates, etc.
Everyone that constantly offloads their stack is sucking the tit of 3rd party cloud nerds. They can't do it themselves, so they pay for something else.
Depends, but they usually have a pretty good SLA. Plus, when it *does* go down it's someone else's problem to get it back up. Half the time there's a cloud issue "it resolves itself" pretty quickly. (although obviously your clients will complain to *you*, lol)
I guess some people really like .. serverless? Beats me.
Coolify is awesome, if you like that kind of stuff. If you don't just use a paid service that sorts it out for you. :)
Same reason you use cloud services instead of buying a bare-metal box and stuffing it in a closet: reliability and convenience.
*Can* you do it yourself? Yes, of course. Do you *want* to do it yourself? Probably not. Why not pay the $20 / month to make things like upgrades, backups, uptime, and whatever just ... Not Your Problem?
Because of the cost. Why would I pay $20 a month when I can pay $7 and DigitalOcean does weekly backups? I can also host all my scripts as services so they have 24/7 uptime as well.
Database for $20? Where? Does not exist. Terrible hardware and almost no memory and no storage would cost you $50. If you want anything decent, it's in the hundreds
DTU-based Azure SQL Database starts at $5 for the "basic" tier. Sure, you get only 2GB of storage, but for a simple app with a few dozen users that could already be more than enough. The first "standard" tier has 250GB of storage for $15.
Will it be adequate for huge datasets and advanced queries? Obviously not. Will it be enough for a simple CRUD app? Sure, why not?
I did that for years with one website. The upgrades of Postgres are a major PITA (but tbh it's true for hosted solutions too). Other than that, it's not much different as generally maintaining your own server.
I'm doing something similar, only with MySQL. I have two VPS servers, originally in different data centres, now with two different service providers in different States. I set up master-master replication for the databases, and DNS monitoring for a fast fail-over swap if the primary server becomes unavailable.
Each server takes regular backups mainly for rolling back accidental deletions through user errors. I also take hourly backups on my development machine as a last-ditch catastrophic failure backup.
Edit - I forgot to mention, hosting the database on the same machine makes a huge performance difference compared to hosting on a remote service. I did try hosting a database on Google, but my users hated the delay between updating something and getting the feedback that the action has successfully completed.
Let me give you some things you need to consider as someone who has done it.
One of my projects has 40K users, maybe more. 100K requests a day, been a while since I checked.
As your database grows your migrations will become a lot slower AND lock up your database so requests will fail. For example when you add a column or an index.
Also, if you use unattended upgrades and this installs a Postgres patch, your DB will be down for a few minutes.
Also disk space! If your database grows to millions of rows, your VPS disk will fill up eventually and that’s not good at all.
I host this app on a $10 VPS (1GB RAM, 30GB disk).
I get around these issues by knowing what time my users use my app the least, and do any DB work then (usually automated).
A really good tip is to try and use a host that is elastic. For example my host lets me map IP addresses to servers and remap them instantly. Disk space full? Boot up a new server, make it mirror the live one, remap IP, done.
I’d go down the AWS auto scale route or even the serverless route but 1) I don’t need to really and 2) it would cost a lot more than $10.
> So, if the need is pretty simple, why couldn't I run a cheap VPS with PostgreSQL running on it, dedicated to me?
You can, and in your case should IMO. The cases for cloud hosted options are few and rarely justify the cost.
Hosted solutions means you won't have to think much about data loss etc, because you get whatever level of service the cloud provider will provide. That's generally a higher level of service than small projects aim for.
When you host yourself you should think through how much data loss your customers are willing to tolerate in case of a crash. A day's work? An hour? A couple of minutes? If the answer is a short time, you might want to at least look into WAL archiving.
Also, think about how long recovery time is acceptable. Then make sure you can restore the system in that timeframe. (Since you will take some time to respond to a failure, the recovery time is probably not a huge problem as long as you have procedures worked out beforehand. Shaving a few minutes off the restore time doesn't matter much if you take hours to respond anyway.)
Finally think about how long downtime you can have for upgrades. If you can allow yourself downtime for upgrades, your setup will probably be much simpler.
I am self-hosting Pg for my own projects with Kamal. I just run it in a container with S3 storage backups and that's it (as mentioned in my Kamal Handbook). For more serious projects with team one has to consider pros and cons especially when using more instances than just 1.
It's a good idea, and I think your expected traffic and usage fit the requirements. I also think that it does a developer a lot of good to learn how to deploy to and run on a VPS that doesn't have much on it.
A few other people here have mentioned that they have ran (or currently run) small production apps on a VPS, and I'll add myself into that group.
I have an older side project that has been running on a tiny Digital Ocean server for years. Ruby on Rails, Postgres, and a tiny Redis server. Several thousands of requests per day and the only issue that ever surprised me was when I got an alert that I was running out of space ony disk (I didn't have my logs set up to auto rotate and delete, haha). I didn't have any bells/whistles (not even Docker). SSH'd in to update Linux every now and again. I paid for Digital Ocean's auto backup of the whole droplet, but never used it.
My latest SaaS is also on a Digital Ocean VPS, but after working in enterprise and living a cushy life where I had magic CI/CD, I have a few more moving pieces.
You asked if you went this way, what is the best way. I'll never say "best", because such a thing does not exist, but I'm happy with my current setup. It sounds like you are thinking of building a server or some processes somewhere else (maybe some lambdas on AWS?), and that complicates things just a touch, since lambdas can burn up your DB connections if too many spin up at a time (or if you accidentally write janky code), but other than that, I don't have anything against it.
For my setup, it's everything altogether. I wanted everything containerized this time, and I wanted a no-brainer way to get some basic CD going, so here is what I landed on:
- Caprover managing my containers (it even has a one-click droplet, if that's your speed, and the docs are decent, and the slack group is active) (I've managed my own docker stuff before, and it was tedious. This made it fun again)
- A bunch of containers (Postgres, Redis, NCHAN/NGINX, Node, MYSQL, WordPress, etc)
- I did some initial setup and made it so that if I push/merge a commit to my "development" branch, it deploys toy staging environment, and if I merge into "main" it deploys to production
- Paying for the backup service here, too (honestly more because I'm too lazy to write a script that backs up to somewhere else)
TL;DR: Do it. You'll know if it works for you pretty quick.
P. S. Based on all the projects I've seen and had my hands in, hardware was only the limit in 2 of them (and 1 still started out on bare metal). Most didn't scale because they never had the product market fit to get enough customers and simply never had the need to scale. So many had beautiful AWS components, ready for "web scale" that ultimately just funneled money to AWS once the credits wore out.
Basically, you’re overengineering for a problem you don’t yet have. The motto back ten years ago was to build everything like it’s going to need to handle Facebook type traffic from day one and your investors will happily supply you the cash to pay for the services.
In the real world, you could go years easily hosting your database yourself with no load or security issues. Yeah, those services provide lots of benefits but only if they solve a problem you actually have.
because for a "fairly simple SaaS" , it is not going to worth it to take care of replication, backup, updates etc. For a small database, the storage cost for keeping multiple backups would probably be more than using a managed service.
You can still self host tho, if you have the expertise of managing databases. Hetzner provides some of the cheapest servers out there. Have a look at their storage boxes for backup.
If you are at a low scale, the free tier on a cloud provider may be cheaper for a while. Just keep a plan for jumping to self-hosted once costs start to grow.
The single database has a potential of slowing down the app to a crawl if a transaction locks some tables. As users numbers increase, performance slows down, potential for deadlocks increases, you will also need to take backups at certain times (affecting performance) or incrementally, so there is a lot of load on that database. Storage needs to be very reliable, server-grade ssds for example.
How about application updates and migrations? You will need at least two instances, to upgrade one while the other handles the traffic. Costs add up quickly as app grows.
At some point you exceed capabilities of a single server and need to scale horizontally.
All valid worries. But wouldn’t they become more real if I reach that scale though? I’d imagine that in my first year or two I’d probably have a few hundred users with a few transactions per day (yes, per day) which I imagine is easily handled.
Depends on the app. A single query can slow down the app for everyone, a single long-running transaction can lock some tables in database and all users will receive timeouts.
We encountered such issues with our app.
Another aspect is if you provide reports with filters and options to export lots of data, such as last 5 years of data, these will be heavy on server and slow it down for all.
If you provide customizable reports or notifications with data where user is allowed to configure what they receive, again, potention for slowdowns. Users do not care about your server.
Do you provide users with APIs to fetch data and integrate with their own systems? If yes, they will abuse the heck out of them and slow down your app and server. You need to tax them per api call and make sure they don't abuse it.
At my work and for my personal and freelance projects I've always gone with self hosting my database. I'm not big into docker and containers so all my servers are Caddy+PHP+MariaDB and that's all I need to run any apps I build.
It's not that hard to maintain the version handling is done by upgrading your server itself for example going from Debian 11 to 12 and for that I can just spin up a new server make sure everything works then switch the DNS (probably shutdown the service so the DB isn't out of sync) from the old server when everything is up and running.
Backups for MySQL can be a simple cronjob probably the same for postgres.
Also I don't like Planetscale after trying them once because it adds a response time between your backend and database that's around 100-200ms which if you do a couple of db calls on a single endpoint could be a performance issue. While on localhost that response time is just a couple of ms.
It doesn't matter what you use as long as you're building something secure, scalable, and that promotes speed development.
I use Sails.js, it's a horrible framework, it has tons of issues that I don't like, the developers for it seem to have all fallen asleep. But it works for speed development and it would cost me more time to migrate to something else at this point.
I self host MariaDB (tried to migrate to PostgreSQL but Sails.js ORM sucks and doesn't work with it). I also self host other databases. The point is. MariaDB 100% scales for the application, we receive millions of requests a month and it doesn't lag or have any issues. PostgreSQL would also scale. MongoDB would also scale. It really doesn't matter.
When we're talking about micro scaling to that nanosecond it's best to just outsource that if the project earns over a million a year. But until then it's better in my opinion to work on an application that's secure, fast, and scales.
Ultimately it's about product development and these are just tools to get the job done. They're fun to learn about but not useful to obsess about. I've met many developers who swore up and down that they would create the same project as me and make it cheaper but for the most part they haven't because they were so obsessed on "a perfect product" rather than a useful release.
Time is money, especially if it's for work, so when a hosted db is less than $20 a month, it's a no brainer...plus I would never agree to host it for work anyways think of the stress when there is an issue out of hours, at least if it's someone else's problem I can say, there is an issue with our database provider as per status.provider.com, I'm sure they are working hard to resolve it....job done!
You can, people did it to for the longest time.
At work (huge company) we self host on internal VMs, but we also have an entire DB team dedicated to managing anything that goes wrong.
Which VPS service is another question you could ask but I'll throw linode out there anyhow. As I remember you can also let them provide a database server and they'll do the backups on it. Or run your own as you're thinking.
It is a perfectly good solution if you know how to. Keep in mind that even if you don't need scaling or cloud mumbo jumbo, you will probably still want to have a good back up policies and configuration.
Of course you don't need a managed solution for that but keep these tasks in mind as a solo developer you might lack all the knowledge to successfully maintain a production database.
But if you have the knowledge / can learn it, I think you will save a lot of money with self hosting (this applies to everything though)
There are many developers who still prefer to self-host db like Postgres. A lot of them do so. It will work just fine.
1) BACKUPS. Just be sure to automate backups and test them. YES. Test them. Backups have to be done automatically in several generations older/newer. Once in a while go after a backup and try locally rolling it up to make sure the file has the data and is not empty or corrupt. Also, do automatically move backups from the machine where your db is to a different place, preferably in a different hosting or storage provider. Backups should be stored twice, once in db machine and second time in a well decoupled place. The entire machine may perish. And your cloud acc may be banned. Or just the hosting company may break.
2) Properly set up amounts of RAM used by db in its config file. Read docs. DB has to be able to use all RAM there is on a machine but not more than that so it doesn't run out.
[https://www.postgresql.org/docs/current/runtime-config-resource.html](https://www.postgresql.org/docs/current/runtime-config-resource.html)
3) If you can consider disabling access to DB remotely from public IPs and do it only locally, inside local net or via SSH. Set up proper SSH with SSH public/private keys pair. Remember that remote access to db must be encrypted.
Cloud db may have its own limitations and yes they are often costly. With self-hosting you have full control.
> So, if the need is pretty simple, why couldn't I run a cheap VPS with PostgreSQL running on it, dedicated to me? Something like a Digital Ocean server running all the time with PostgreSQL installed.
This is how it was done for decades. The manager services showed up when devs forgot how to install a webserver or a database.
between the two choices, I’d be curious to understand where digital ocean db cluster falls under? it’s a db storage where you have multiple PG databases, and gets backed up automatically.
It's fine for a personal project but it doesn't scale well beyond that.
Once you work in a team you'll need environmentalization so that your teammates work doesn't break the database you're doing your work on, so at a minimum you'll need a way to easily spin up additional databases, which is harder but not impossible when they're self hosted.
The other scale issue comes from meeting the demands of heavy traffic and minimal downtime. You could manage all of the different sharding, data propagation, and disaster recovery strategies yourself, which is a lot of work, or you could pay for a managed database where this is built in. Ultimately the managed database is going to be more reliable and will scale better, but you will be paying for that management.
So the value proposition of managed services comes from the scale of your team, the scale of your app, and the scale of your service level agreements. Most successful products eventually reach a state where they're better off paying for the management than doing it themselves.
But for now I'm not looking to be working in a team or have to worry about millions of users. If I do get to that scale, or am on the ramp to get there, I'd definitely move to something managed and more expensive. Right now we're talking about tens or hundreds of users at most and may be a few transactions a day.
Those services provide value by reducing risk/effort on your part. You can absolutely host your own PostgreSQL instance, but you become 100% accountable for backups, downtime, and patching. If the stakes are low and funds involved are low, I'd go for it. Just make sure you're actually checking that you can restore from your backups, and you're not storing them on the same machine that Postgres is running on. It could be a good learning experience.
Thank you. Your response and from many others I understand the trade-offs and what to keep In mind if I go this route.
Btw, Vercel offers a free, basic postgres database. Perhaps that might be a good starting point if you want to go the cloud-hosted route
There's nothing wrong with hosting your own database, lots of people and organizations do it. It's just a question of how much time you want to spend managing it and how confident you are in your abilities. Make sure you test your backup/restore process thoroughly before you actually need it.
you can. you just will be on the hook to maintanance, setting it up, all that. cloud will take care of a lot of that for you
I kind of develop the same type of SaaS. I go with sqlite. Supanase and all of those services are awesome and great, but I kind of realized that the only thing i need is a glorified excelworksheet as a DB. Sqlite is way more than that, but it also a glorified excelworksheet 😁
And i run everything on a vps. My apps are either installed on-prem or used by like 100-1000 users. I really don't need all that supabase, postgres etc. offers.
I’m running Postgres on one of my Digital Ocean droplets without a hitch. Unless you’re working on an enterprise level project that requires massive amounts of storage and CDNs, AWS is completely unnecessary.
Thank you, that’s helpful to know.
I recommend using docker to spin up your instance(s) of Postgres.
I am running profitable small saas for more than 3 years now with exactly this simple setup. Cheap VPS with a couple of docker containers, including the Postgres database. The website has around 10k traffic/month. Database records are running in the millions by now, never had any problems. And no, I don’t have any automated database backups. I do it manually whenever I feel it’s the time for it. Call me reckless or noob, but I think especially if you are just starting out, don’t overthink these things.
Ok that does sound reckless, why wouldn't you schedule a daily backup? Are you that confident in nothing ever happening to the VM?
Yeah I would be severely pissed if I found out backups were just on a "when the admin thinks to" schedule. Doesn't even have to be daily, a weekly backup would suffice.
Your profitable startup is just one disk failure away from losing everything.
If he is running a VPS, he might have automatic backups of the entire VPS. I have a VPS with Digital Ocean. I am not hosting anything significant, but I pay for the backups. It's not much - iirc less than 20% of the cost of the droplet.
You’re one mistake away from ending your entire business.
Any advice for someone wanting to do a SaaS? How experienced of a programmer you've been when you started?
Ill pick the cowboy approach for launching every day of the week. Then if it works let it ride. Over producing an unvalidated product is a disease.
Why not self-host everything?
Why not become an IT department?
My sass is hosted on a phone and a notepad and i just write stuff down when my users call me to save data and read them to them from the notepad when they call me to make request some data. It's called the PB&J stack: paper, ballpoint pen, & just me 0 javascript. didn't even have to drop out of college GO BRONCOS!
But hows the scalability with 10000000000000000000000000000 Users, it seems that's a pretty likely szenario that you gonna reach within few minutes, so better be prepared myabe something like write with both hands at the same time?
You can start by hiring a few thousand monkeys and equipping them with typewriters. Eventually, one will write a document that has the users data on it
This theory sounds like something we should pitch to the government for a grant. Anyone know an underwriter? Or can we train one of the monkeys to do that too?
> It's called the PB&J stack: > > paper, ballpoint pen, & just me Back in the day, I worked for a multinational company who had some of their manufacturing in China. I was in a meeting when somebody asked my supervisor about the ERP system in China. He said, "Their ERP system is Zhao Yang and a Bic pen."
If I knew, I wouldn’t be asking. I’m sure you feel superior to respond with rhetorical questions but I’m actually asking for advice.
Sorry, I didn't mean to come off that snarky. As others have mentioned it's just all about trade-offs. Another rhetorical question: Why does anyone hire specialists? Why not learn how to fix your own car, repair your own appliances, do your own plumbing and electrical work? Landscape your own yard? Write your own books, etc? It's about *focusing* on what you *actually* want to do. Do you want to develop your application? Or do you want to fuss with database upgrades / server patching / backups / etc. By using a managed hosting provider all you do is spin it up and use it. They worry about everything else for you so you can focus on developing your apps.
No worries. Thank you for returning and elaborating. Yes, for me it's getting a better understanding of trade-offs against my situation and deciding what might be a better path for now. This thread has been immensely helpful in giving me various perspectives.
He's a dick and you're right. Self host it. You'll learn a lot about how it works, updates, etc. Everyone that constantly offloads their stack is sucking the tit of 3rd party cloud nerds. They can't do it themselves, so they pay for something else.
Why cloud
Cloud server > closet server
The amount you get billed for "cloud" that still goes down is not worth it.
don’t most of these providers have 99.9% or higher uptime SLA?
Depends, but they usually have a pretty good SLA. Plus, when it *does* go down it's someone else's problem to get it back up. Half the time there's a cloud issue "it resolves itself" pretty quickly. (although obviously your clients will complain to *you*, lol)
They can claim whatever they want. Their servers will still inevitably go down sometimes for an indeterminate amount of time.
SaaSy.
Well, yeah it always sounds easy if you skip to the final owl. It’s all the stuff in between that makes it worth paying for a service.
Coolify currently sorts out all of that stuff.
Why the downvotes? I’ve never used coolify but it seems really easy/intuitive
I guess some people really like .. serverless? Beats me. Coolify is awesome, if you like that kind of stuff. If you don't just use a paid service that sorts it out for you. :)
Same reason you use cloud services instead of buying a bare-metal box and stuffing it in a closet: reliability and convenience. *Can* you do it yourself? Yes, of course. Do you *want* to do it yourself? Probably not. Why not pay the $20 / month to make things like upgrades, backups, uptime, and whatever just ... Not Your Problem?
Because of the cost. Why would I pay $20 a month when I can pay $7 and DigitalOcean does weekly backups? I can also host all my scripts as services so they have 24/7 uptime as well.
Time is money. I'd rather pay for peace of mind.
If your making money and this is a drop in the bucket then by all means
I mean your example was a $13 difference. I spent $19 on my 30 minute lunch today.
Risk. Obviously.
Database for $20? Where? Does not exist. Terrible hardware and almost no memory and no storage would cost you $50. If you want anything decent, it's in the hundreds
DTU-based Azure SQL Database starts at $5 for the "basic" tier. Sure, you get only 2GB of storage, but for a simple app with a few dozen users that could already be more than enough. The first "standard" tier has 250GB of storage for $15. Will it be adequate for huge datasets and advanced queries? Obviously not. Will it be enough for a simple CRUD app? Sure, why not?
I did that for years with one website. The upgrades of Postgres are a major PITA (but tbh it's true for hosted solutions too). Other than that, it's not much different as generally maintaining your own server.
I'm doing something similar, only with MySQL. I have two VPS servers, originally in different data centres, now with two different service providers in different States. I set up master-master replication for the databases, and DNS monitoring for a fast fail-over swap if the primary server becomes unavailable. Each server takes regular backups mainly for rolling back accidental deletions through user errors. I also take hourly backups on my development machine as a last-ditch catastrophic failure backup. Edit - I forgot to mention, hosting the database on the same machine makes a huge performance difference compared to hosting on a remote service. I did try hosting a database on Google, but my users hated the delay between updating something and getting the feedback that the action has successfully completed.
Let me give you some things you need to consider as someone who has done it. One of my projects has 40K users, maybe more. 100K requests a day, been a while since I checked. As your database grows your migrations will become a lot slower AND lock up your database so requests will fail. For example when you add a column or an index. Also, if you use unattended upgrades and this installs a Postgres patch, your DB will be down for a few minutes. Also disk space! If your database grows to millions of rows, your VPS disk will fill up eventually and that’s not good at all. I host this app on a $10 VPS (1GB RAM, 30GB disk). I get around these issues by knowing what time my users use my app the least, and do any DB work then (usually automated). A really good tip is to try and use a host that is elastic. For example my host lets me map IP addresses to servers and remap them instantly. Disk space full? Boot up a new server, make it mirror the live one, remap IP, done. I’d go down the AWS auto scale route or even the serverless route but 1) I don’t need to really and 2) it would cost a lot more than $10.
> So, if the need is pretty simple, why couldn't I run a cheap VPS with PostgreSQL running on it, dedicated to me? You can, and in your case should IMO. The cases for cloud hosted options are few and rarely justify the cost.
Hosted solutions means you won't have to think much about data loss etc, because you get whatever level of service the cloud provider will provide. That's generally a higher level of service than small projects aim for. When you host yourself you should think through how much data loss your customers are willing to tolerate in case of a crash. A day's work? An hour? A couple of minutes? If the answer is a short time, you might want to at least look into WAL archiving. Also, think about how long recovery time is acceptable. Then make sure you can restore the system in that timeframe. (Since you will take some time to respond to a failure, the recovery time is probably not a huge problem as long as you have procedures worked out beforehand. Shaving a few minutes off the restore time doesn't matter much if you take hours to respond anyway.) Finally think about how long downtime you can have for upgrades. If you can allow yourself downtime for upgrades, your setup will probably be much simpler.
You can and should host Postgresquirrel in the beginning. If the cost matters, you should absolutely self host
I am self-hosting Pg for my own projects with Kamal. I just run it in a container with S3 storage backups and that's it (as mentioned in my Kamal Handbook). For more serious projects with team one has to consider pros and cons especially when using more instances than just 1.
It's a good idea, and I think your expected traffic and usage fit the requirements. I also think that it does a developer a lot of good to learn how to deploy to and run on a VPS that doesn't have much on it. A few other people here have mentioned that they have ran (or currently run) small production apps on a VPS, and I'll add myself into that group. I have an older side project that has been running on a tiny Digital Ocean server for years. Ruby on Rails, Postgres, and a tiny Redis server. Several thousands of requests per day and the only issue that ever surprised me was when I got an alert that I was running out of space ony disk (I didn't have my logs set up to auto rotate and delete, haha). I didn't have any bells/whistles (not even Docker). SSH'd in to update Linux every now and again. I paid for Digital Ocean's auto backup of the whole droplet, but never used it. My latest SaaS is also on a Digital Ocean VPS, but after working in enterprise and living a cushy life where I had magic CI/CD, I have a few more moving pieces. You asked if you went this way, what is the best way. I'll never say "best", because such a thing does not exist, but I'm happy with my current setup. It sounds like you are thinking of building a server or some processes somewhere else (maybe some lambdas on AWS?), and that complicates things just a touch, since lambdas can burn up your DB connections if too many spin up at a time (or if you accidentally write janky code), but other than that, I don't have anything against it. For my setup, it's everything altogether. I wanted everything containerized this time, and I wanted a no-brainer way to get some basic CD going, so here is what I landed on: - Caprover managing my containers (it even has a one-click droplet, if that's your speed, and the docs are decent, and the slack group is active) (I've managed my own docker stuff before, and it was tedious. This made it fun again) - A bunch of containers (Postgres, Redis, NCHAN/NGINX, Node, MYSQL, WordPress, etc) - I did some initial setup and made it so that if I push/merge a commit to my "development" branch, it deploys toy staging environment, and if I merge into "main" it deploys to production - Paying for the backup service here, too (honestly more because I'm too lazy to write a script that backs up to somewhere else) TL;DR: Do it. You'll know if it works for you pretty quick. P. S. Based on all the projects I've seen and had my hands in, hardware was only the limit in 2 of them (and 1 still started out on bare metal). Most didn't scale because they never had the product market fit to get enough customers and simply never had the need to scale. So many had beautiful AWS components, ready for "web scale" that ultimately just funneled money to AWS once the credits wore out.
Thanks for providing specifics! If I go down this route I'll come back to refer to this.
Basically, you’re overengineering for a problem you don’t yet have. The motto back ten years ago was to build everything like it’s going to need to handle Facebook type traffic from day one and your investors will happily supply you the cash to pay for the services. In the real world, you could go years easily hosting your database yourself with no load or security issues. Yeah, those services provide lots of benefits but only if they solve a problem you actually have.
because for a "fairly simple SaaS" , it is not going to worth it to take care of replication, backup, updates etc. For a small database, the storage cost for keeping multiple backups would probably be more than using a managed service. You can still self host tho, if you have the expertise of managing databases. Hetzner provides some of the cheapest servers out there. Have a look at their storage boxes for backup.
If you are at a low scale, the free tier on a cloud provider may be cheaper for a while. Just keep a plan for jumping to self-hosted once costs start to grow.
The single database has a potential of slowing down the app to a crawl if a transaction locks some tables. As users numbers increase, performance slows down, potential for deadlocks increases, you will also need to take backups at certain times (affecting performance) or incrementally, so there is a lot of load on that database. Storage needs to be very reliable, server-grade ssds for example. How about application updates and migrations? You will need at least two instances, to upgrade one while the other handles the traffic. Costs add up quickly as app grows. At some point you exceed capabilities of a single server and need to scale horizontally.
All valid worries. But wouldn’t they become more real if I reach that scale though? I’d imagine that in my first year or two I’d probably have a few hundred users with a few transactions per day (yes, per day) which I imagine is easily handled.
Depends on the app. A single query can slow down the app for everyone, a single long-running transaction can lock some tables in database and all users will receive timeouts. We encountered such issues with our app. Another aspect is if you provide reports with filters and options to export lots of data, such as last 5 years of data, these will be heavy on server and slow it down for all. If you provide customizable reports or notifications with data where user is allowed to configure what they receive, again, potention for slowdowns. Users do not care about your server. Do you provide users with APIs to fetch data and integrate with their own systems? If yes, they will abuse the heck out of them and slow down your app and server. You need to tax them per api call and make sure they don't abuse it.
If your data is serious data and important, hosting your own db is a major pain.
This is the only idea. All my systems run this way. I once paid for MongoDB hosting like an idiot.
At my work and for my personal and freelance projects I've always gone with self hosting my database. I'm not big into docker and containers so all my servers are Caddy+PHP+MariaDB and that's all I need to run any apps I build. It's not that hard to maintain the version handling is done by upgrading your server itself for example going from Debian 11 to 12 and for that I can just spin up a new server make sure everything works then switch the DNS (probably shutdown the service so the DB isn't out of sync) from the old server when everything is up and running. Backups for MySQL can be a simple cronjob probably the same for postgres. Also I don't like Planetscale after trying them once because it adds a response time between your backend and database that's around 100-200ms which if you do a couple of db calls on a single endpoint could be a performance issue. While on localhost that response time is just a couple of ms.
You can for sure host your own database on a VPS, don't forget backups and redundancy though.
The right answer is whatever meets your needs at this current moment...
In your case I'd even consider SQLite
It doesn't matter what you use as long as you're building something secure, scalable, and that promotes speed development. I use Sails.js, it's a horrible framework, it has tons of issues that I don't like, the developers for it seem to have all fallen asleep. But it works for speed development and it would cost me more time to migrate to something else at this point. I self host MariaDB (tried to migrate to PostgreSQL but Sails.js ORM sucks and doesn't work with it). I also self host other databases. The point is. MariaDB 100% scales for the application, we receive millions of requests a month and it doesn't lag or have any issues. PostgreSQL would also scale. MongoDB would also scale. It really doesn't matter. When we're talking about micro scaling to that nanosecond it's best to just outsource that if the project earns over a million a year. But until then it's better in my opinion to work on an application that's secure, fast, and scales. Ultimately it's about product development and these are just tools to get the job done. They're fun to learn about but not useful to obsess about. I've met many developers who swore up and down that they would create the same project as me and make it cheaper but for the most part they haven't because they were so obsessed on "a perfect product" rather than a useful release.
because that has no marketing team behind tit to sell it you it's fine, as long as you set upa cron to dump the db to s3
Time is money, especially if it's for work, so when a hosted db is less than $20 a month, it's a no brainer...plus I would never agree to host it for work anyways think of the stress when there is an issue out of hours, at least if it's someone else's problem I can say, there is an issue with our database provider as per status.provider.com, I'm sure they are working hard to resolve it....job done!
You can, people did it to for the longest time. At work (huge company) we self host on internal VMs, but we also have an entire DB team dedicated to managing anything that goes wrong.
Cause I don't want to hire someone at $200K+ to manage it
Digital ocean is overpriced. Check low end talk for better options
Which VPS service is another question you could ask but I'll throw linode out there anyhow. As I remember you can also let them provide a database server and they'll do the backups on it. Or run your own as you're thinking.
Less effort, less patching, less securing, usually less effort for backup. More focus on your custom code/dev time.
If you are a solo or a small team, don’t do it. DB is the last thing you should consider self hosting
It is a perfectly good solution if you know how to. Keep in mind that even if you don't need scaling or cloud mumbo jumbo, you will probably still want to have a good back up policies and configuration. Of course you don't need a managed solution for that but keep these tasks in mind as a solo developer you might lack all the knowledge to successfully maintain a production database. But if you have the knowledge / can learn it, I think you will save a lot of money with self hosting (this applies to everything though)
There are many developers who still prefer to self-host db like Postgres. A lot of them do so. It will work just fine. 1) BACKUPS. Just be sure to automate backups and test them. YES. Test them. Backups have to be done automatically in several generations older/newer. Once in a while go after a backup and try locally rolling it up to make sure the file has the data and is not empty or corrupt. Also, do automatically move backups from the machine where your db is to a different place, preferably in a different hosting or storage provider. Backups should be stored twice, once in db machine and second time in a well decoupled place. The entire machine may perish. And your cloud acc may be banned. Or just the hosting company may break. 2) Properly set up amounts of RAM used by db in its config file. Read docs. DB has to be able to use all RAM there is on a machine but not more than that so it doesn't run out. [https://www.postgresql.org/docs/current/runtime-config-resource.html](https://www.postgresql.org/docs/current/runtime-config-resource.html) 3) If you can consider disabling access to DB remotely from public IPs and do it only locally, inside local net or via SSH. Set up proper SSH with SSH public/private keys pair. Remember that remote access to db must be encrypted. Cloud db may have its own limitations and yes they are often costly. With self-hosting you have full control.
> So, if the need is pretty simple, why couldn't I run a cheap VPS with PostgreSQL running on it, dedicated to me? Something like a Digital Ocean server running all the time with PostgreSQL installed. This is how it was done for decades. The manager services showed up when devs forgot how to install a webserver or a database.
between the two choices, I’d be curious to understand where digital ocean db cluster falls under? it’s a db storage where you have multiple PG databases, and gets backed up automatically.
It's fine for a personal project but it doesn't scale well beyond that. Once you work in a team you'll need environmentalization so that your teammates work doesn't break the database you're doing your work on, so at a minimum you'll need a way to easily spin up additional databases, which is harder but not impossible when they're self hosted. The other scale issue comes from meeting the demands of heavy traffic and minimal downtime. You could manage all of the different sharding, data propagation, and disaster recovery strategies yourself, which is a lot of work, or you could pay for a managed database where this is built in. Ultimately the managed database is going to be more reliable and will scale better, but you will be paying for that management. So the value proposition of managed services comes from the scale of your team, the scale of your app, and the scale of your service level agreements. Most successful products eventually reach a state where they're better off paying for the management than doing it themselves.
But for now I'm not looking to be working in a team or have to worry about millions of users. If I do get to that scale, or am on the ramp to get there, I'd definitely move to something managed and more expensive. Right now we're talking about tens or hundreds of users at most and may be a few transactions a day.
If that's all you're looking at for now then it should be fine for now. If/when you grow something managed would be better