No Compromises

You launched a hobby project and then it starts to get some traction. What next? How do you get a more solid foundation under your app when it comes to database hosting? In this episode, we discuss the common phases we see a database go through during an app's life.

And if you'd love some help moving your database or tackling performance issues, give us a call!

Creators & Guests

Host
Aaron Saray
Host
Joel Clermont

What is No Compromises?

Two seasoned salty programming veterans talk best practices based on years of working with Laravel SaaS teams.

Joel:

Welcome to No Compromises. A peek into the mind of two old web devs who have seen some things. This is Joel.

Aaron:

And this is Aaron.

Joel:

I'm a simple man, so I like to talk about things that are fresh in my brain. And, that's why I thought today's topic could be kind of around, I'm gonna say, like, database maintenance, monitoring, performance, just just sorta in there because it's it's something I've been working on, and focusing on the last couple weeks. So is that alright with you, Aaron?

Aaron:

Yeah. So more like the path, like, how you start out with your database.

Joel:

Yeah.

Aaron:

You know, like those memes, how you started out and how it's going. But but, no. Like, how you start out when you have initial application, not over architecting, and then moving through the stages of as your traffic and requirements grow.

Joel:

Yeah. Yeah. That that's that's a good way of framing it because you could, when you're starting that new app idea, go nuts and, like, architect the most resilient database infrastructure from day one. But but most people don't do that, and I don't think we would even recommend that. Obviously, it's gonna depend on what what it is you're trying to build and who it's for, but let let's just kinda take the I I don't know if if it's the happy path or the normal path, but in in the Laravel yeah.

Aaron:

Let's start at hobby level. Let's just say you're launching a Laravel hobby project. What what do you do with your database? Walk me through that that process.

Joel:

I'm gonna talk about it from the perspective of somebody using Laravel Forge because I think, number one, a lot of people do use that, and number two, I think even if you don't, it's, like, not a bad thing to consider if you're spinning up a hobby project. So what Forge will do for you is provision your web server. But, you know, there's, like, there's all the stuff you need with a web app. You might need Redis. You might need a queue worker.

Joel:

You certainly probably need a database. And so when you go to provision a server on Forge, it gives you some options about which of those services you want. And even within Forge, like, there there's a bunch of choices you could make, but I think the default path or at least the path I see a lot of people take is I'm just gonna provision my database right on my web server. You know, I got maybe I got one of those $10 a month DigitalOcean Machines. I'm just getting this started.

Joel:

Like you said, it's a hobby site. I'm just gonna slap MySQL, let's just keep it in MySQL, right on the web server with me.

Aaron:

Right. Yeah. That makes sense. So we're starting out, we're basically putting everything all in one server and calling it good. Sounds good.

Aaron:

Right.

Joel:

And I'll be honest, Like, you can run a long time in that that scenario. In fact, we see clients that have successful real world SaaS applications serving thousands, if not tens of thousands of users in that scenario. Right? So I'm I'm not dismissing it, and I'm not saying it's bad, but there's going to reach a point. And usually, the point is you start to have some sort of performance issue.

Joel:

Right? It might be one particular thing is slow or certain times of the day, the whole site gets slow or even worse, like, certain times of the day, the site becomes nonresponsive and you start getting errors. And so, like , when you reach that point, you have a couple choices in front of you. Right? Choice one, I'll just make the server bigger.

Joel:

Right? Like, if you're on DigitalOcean or AWS, you can log into the control panel and say, I want more RAM. I want more CPUs. Right? So that is a path you could take.

Joel:

It's maybe the easiest path, but also it comes with the cost. The other path, and what I would...

Aaron:

Let's just make sure we understand. The cost is, at that time, smaller than the cost of programming, though.

Joel:

That's true. That's why it is alluring as well. Right? Like, I just my credit card bill will go up a little bit, and in 5 minutes, my problem will be solved. Right?

Joel:

It's programmer time and, like, also, if, like, if you became aware of this because customers are complaining, that's probably not the time you wanna be like, what are my options here? Right? Like, you just wanna get this fixed.

Aaron:

You just you

Joel:

just wanna want the phone to stop ringing or emails to stop coming in.

Aaron:

And let's just say let be real clear. You wanted to be to stop being broken, not fixed.

Joel:

Okay.

Aaron:

Yeah. I mean, there's a difference there because Yeah. I wanna make sure we don't give the wrong advice either is Mhmm. If if something slow, customers are calling in, and you bump up the stuff, that's not the end of it.

Joel:

Right.

Aaron:

That stops it being broken. But you need to actually, take the time then to figure out if there was something that you need to fix. Or, you know, is this just what you need now? And sometime, I would say a good portion of the time, it's not just what you need now. I mean, it's not bad to have more server stuff.

Aaron:

But, usually, it points to something, some sort of programming. And so I think I wanna go on a a little side tangent here. I'm sorry. I'm derailing us.

Aaron:

Yeah. But, so back in the day, when old men like us started programming, programmer time was was more, accessible or cheaper than hardware and swapping this stuff out. Right? So When we talked about hosting something, it was on, like, shared hosting or on metal, you know, stuff inside of a a data center. So if you wanted to bump up your CPU, that meant contacting the server company and saying, I'd like to swap out to the newest Xenon I3 or whatever, you know, was crazy at the time.

Aaron:

Right? And so you would go and say, maybe let's spend a little bit more time on with our programmers instead and optimize our stuff. And then technology changes. And then we got to this point where the changes in technology, being able to virtualize stuff and move things around and stuff, became cheaper than most programmers' time. Right?

Aaron:

Yeah. And that doesn't mean that one or the other is the actual solution. It just means at this point in time, those things are cheaper. Now imagine a scenario where everyone in the whole world, every single human being could program. Well, then it would probably be cheaper to program again than to upgrade your software.

Aaron:

So you just have to kinda keep an eye on or upgrade your hardware. Just you have to keep an eye on what makes most sense at this cycle of the time.

Joel:

Is that the world you dream of, Aaron, where everybody programs, or is that a nightmare for you?

Aaron:

Oh, I mean, a little bit of both.

Joel:

Okay. Alright. I don't want a tangent off our tangent. But Yeah. Okay.

Joel:

Yeah. That's that's good context, and and it's it's a good thing to have in the back of your mind when you're in the middle of that decision, but I am glad you clarified. We didn't actually fix it. We just made the symptom go away. Like, you know, we slapped an extra Band Aid on the bleeding wound so that we're not getting blood on the carpet.

Joel:

This is getting kinda gross. Sorry. But anyways Yeah.

Aaron:

You have to change the rating of the podcast.

Joel:

Yeah. Exactly. So alright. So path one is just throw more hardware at the problem, I guess, is, like, a common way of referring to that. But it could be a time to consider maybe the database server shouldn't be on the web server. And there's there's two reasons for that. Like, performance is one. Right? A database needs memory, so do those web requests that PHP is serving. Right?

Joel:

All of those things require memory, and so they're somewhat in contention with each other. But I think there's another benefit to separating them as well, which is, well, if you separate it, you could just spin up your own server and have Forge provision MySQL on it. But but I think the more interesting path is to maybe consider, like, a managed database service. And so the two common places we host applications, DigitalOcean and AWS, both offer something like this. And the pricing is actually not that much more than what you would pay to spin it up yourself and put the hardware on it.

Joel:

Right? It's it's a marginal additional cost. It's not, like, double or triple the cost. It's maybe like I don't know. I'm making up numbers, but maybe it's, like, 20% more versus you setting it up yourself.

Joel:

But what you get for that is you don't have to apply patches. Backups is a huge one. A lot of people I see that are running a database server on their web server, they don't really have a good strategy for backups. Like, maybe they take daily backups. That's probably about the best common thing I see, but they're not likely set up to do a point in time backup.

Joel:

You know, a customer accidentally deleted something at 12:30. They called you at 2 PM. Your last database backup is from midnight. Right? Like, so all these managed services, at least the ones I looked at, the the providers I I just talked about, it's just that's table stakes.

Joel:

Like, you get that when you spin it up, it's point in time backup. And for, like, a rolling period of maybe a week or a month, like and sometimes it's configurable. Sometimes the longer you set it, it incurs a little additional cost. But it's just a whole realm of knowledge you don't have to specialize in because, like, tuning that and and sizing it and setting up backups and replication, I'm not even talking about that. Like, there's all these things that you just get as, like, a checkbox in a user interface that before, you'd have to invest some serious time to set that up and configure it.

Aaron:

Well, remember, it's just kinda like I what I rambled upon before is that we used to have servers and put them in a server closet and Mhmm. All this stuff. It is I mean, I guess I haven't done the numbers recently, but it probably is cheaper to still have your own servers and do those kind of stuff and you get to a certain level. Yeah. You know, actually probably a lot sooner than people realize.

Aaron:

I mean, otherwise, if that wasn't the case, how would AWS, you know, be making so much money? Right? It is cheaper to technically have these servers. But you get so much more out of being able to, you know, parcel them a little tiny and click in the interface. And Yeah.

Aaron:

It costs more, but you get so much more for it. I think that's the same thing with this database setup is it technically probably costs a little bit more than spinning up just a separate droplet or something in DigitalOcean, but you get so much more. And just the way now that I don't wanna go back to putting stuff in a data center, you'll not wanna go back to running your own MySQL server because this is just Yeah. It's a little bit more, but it takes all the headache away.

Joel:

Yeah. Absolutely. So there's one more topic I wanna talk about that is related to this. And so let's talk about you've made that decision. Right?

Joel:

You're gonna move off of the database hosted on your web server to a managed service. The next thing you're probably going to run into is those managed services generally are a little bit more tightly configured. And what I mean by that is, like, again, using MySQL as an example, there's all sorts of different server options and strictness modes and different things that can be configured one way or another that for performance reasons are gonna be, by default, tuned more strictly in one of these managed services. So I'll give an example specific example that I frequently run into. Do you remember when MySQL allowed you to have a date that was all zeros?

Joel:

Aaron, you remember that.

Aaron:

Yeah. I remember that.

Joel:

Just a little PTSD from from those days. But you know what? Maybe it was a good idea at the time. We're not gonna get into that. But with MySQL 8, I think, that default flipped from allowing it to not allowing it.

Joel:

And, actually, it might have been flipped a little earlier than that. It might have been I think it

Aaron:

was definitely earlier than that.

Joel:

Okay. And maybe it's in 8, like, you really have to go out of your way to that to not to to allow those 0 dates. And so that that's just one example. There are probably a dozen examples like this.

Joel:

Another one I bumped into with DigitalOcean because of the way it does replication, it forces you all of your tables have to have primary keys. Now you can open a support ticket and have them turn that option off, and they'll tell you why it's bad, but you can do it. But there's there's things like this where you you wanna factor this in because kind of to that original point of, like, the difference between something not being broken and actually being fixed, this would be a good time to kinda clean up. I'm gonna call it technical debt, data debt, you know, messiness when you're doing the migration. Don't just, like, flip all the settings back to the older, maybe more insecure, messier standards.

Joel:

Take that opportunity to clean things up and kinda bring it forward as part of the migration.

Aaron:

And then the sort of because we we always need to have the the business reason for this Yeah. Stuff. Right? Yeah. So you can always say, you know, performance of the database, blah blah blah, but that's kinda wishy washy.

Aaron:

I mean, that's as a former manager, even though I knew the answer was sometimes that, sometimes it also felt like just something developers say when they can't think of anything else to say.

Joel:

It'll be fast.

Aaron:

It's a fast better performance. Like, yeah. Show me. Yeah. Right.

Aaron:

But the other the other thing on this is that it does like, for example, getting rid of the zero dates. Yeah. You can legitimately point at your code and say, now we only have to check for null. So we don't have to say Sure. Where is null or where date equals 0000-00-00 dash whatever.

Aaron:

Yeah. I don't want those. I wanna filter those out. And so you can say, you know, we do have to take care of some data migration, some cleanup, which is gonna be great for your reporting tools if you're using other ones.

Joel:

Yeah.

Aaron:

As well as we're gonna be able to strip out some of these if statements or these combined wheres, and that reduces our bugs too. Yeah. So it's not even performance. It's also about reducing bugs. And that's the that's the 2 keywords that, you know, you might wanna just inject in there as well as it's performance and no more bugs, then I'm more interested.

Joel:

That that's that's an excellent point. I appreciate that segment of Aaron's manager corner because , yeah, we can get focused on, like you could take the other tack. Right? And be like, well, if we gotta change all this stuff, why are we doing this? Why are we migrating to this service?

Joel:

It seems like a bad idea. Right? Like, if you frame it the wrong way, you might not get the results you're looking for. Alright.

Aaron:

So I like to think that I'm a secure man. I don't have any worries when I go out places and stuff like that. You know, but, my sister came to visit me. And my middle sister, she's from a couple hours away. And so we went out to eat.

Aaron:

And I went out to this Asian restaurant. And they set us down. And I was underneath like a cherry tree. They put us in a booth. It was almost, like, romantic.

Joel:

Okay. I'm trying to set a mood.

Aaron:

Yeah. Because, I mean, I'm sure it looked like, you know, a couple or something. But I'm like, you know, I I know what they mean when they say, like, couple start to look like each other. But, I mean, this is pretty bad. So I guess I would ask you, Joel.

Aaron:

I'm looking for advice. How do I feel how do I feel more comfortable? Or how do I, take out my sisters? Because I have 2 of them. Mhmm.

Aaron:

Without, you know, saying, these are my sisters. And, like, trying to tell, like, maybe the single, ladies that I am not taken.

Joel:

Well, I have First of all, you're asking the guy who has no siblings, so that's great. I'm you're drawing on my deep experience with this topic. Mhmm. You one thing you could do is take out both sisters at the same time. Like, would that shift the dynamic where they'd be like, this guy doesn't have 2 wives.

Joel:

Right? Like, that'd be kinda weird. So maybe name tags, like, you know, or or you could have custom shirts made up. You know, like, the joke shirt, I'm with stupid. You could be like, I'm with my sister.

Joel:

I'm just riffing here. I don't know.

Aaron:

So would say I'm with stupid?

Joel:

Oh, boy.

Aaron:

As the famed, intelligent, and highly lauded offspring once said, you gotta keep them separated.

Joel:

Aaron you were just looking for a reason to say that. But if you need help separating your database, give us a call. Head over to nocompromises.io and click that book a call link.