 And so I'm gonna be sharing some lessons learned, some thoughts about how to migrate to Postgres, things you should be keeping in mind as you try to use Postgres more and more. If you're here at the conference, you've probably learned a lot and you probably already love Postgres or at least you're starting to like it and maybe starting to love it a little bit more. And if you're like me or a lot of folks here, you wish all your databases were running in Postgres. But most folks don't actually get that opportunity. You've got your side base, you've got your legacy oracle, whatever it is, you don't get to use Postgres for everything. You're stuck a little bit. So the question is, why should you migrate to Postgres and how do you go about doing it? So the why is pretty simple, right? There are a lot of good reasons to migrate to Postgres. Obviously, the open source flexibility is great, the responsive community, the guys up here just talked about it, how quickly the community is able to add features based on demand, et cetera. The advanced features, very high performance, millions of transactions, scale out capabilities. And of course, if you're talking about moving from one of the commercial databases, there's an opportunity to save some money. So migrating to Postgres is a good idea. Now, how do you go about doing it? And when you think about planning your migration to Postgres, there are some things that you should think about and ways to approach it. So the first thing is really just think outside the database. So you might be a DBA, you might be a database developer, you spend your time dealing with either Postgres or other databases, you worry about your schema, you worry about your data, you worry about your stored procedures and your code, and you're really good at it. But when you're migrating, when you're moving your data platform, there's a lot other than the database that you need to worry about. So you need to go talk to your application developers, you need to learn how are they using the database, how are they making those database calls? Are they using an ORM that's gonna be easy? Do they have a lot of custom SQL in the code? That determines how easy it's gonna be. You need to plan for your testing, right? If you move your database platform, your application might behave differently. How are you gonna test that? Environments, planning, working with the testing team to have a set, test data, all of that matters. And how are you gonna do your performance testing? If you've got a big database, if you've got a big application, yeah, you've got your sample QA database, yeah, you tested it with two users, that doesn't show you that it's gonna perform well. You really need to think about how are you gonna do your performance testing so that when you go live, you're not surprised. You don't have a shock. And what are your deployment requirements? How are you gonna get it out there? What kind of HA do you need? What type of recovery? How are you gonna do backups? How are you gonna work with the ops team? They're gonna need to know how to support Postgres. They're gonna need to know how to use it. And what are they gonna have to do differently than what they're doing today? And then really, from a training standpoint, your application developers, your other application or database users, they may not know anything about Postgres. You've gotta think about how do you make them successful? Because even if you get the data over, even if you get your tables over, if you don't think about the other things that are surrounding the database, it's not gonna be a successful migration. So you gotta think outside the database, think about all those bits and pieces to really work. And a lot of times when we think about doing a migration, we say, hey, maybe there's a great automated tool. And there are some really good tools. You should look at, if you're moving from Oracle to Postgres, you should look at the ORA 2PG project. It's a really good tool. You should take a look maybe at the schema conversion tool. These are good tools that can get you 50, 60% of the way there. They do a lot of the work for you. But they're not gonna be silver bullets. And if you get 90% of your database moved over, 90% of your code over, it's not done. You still have a lot of work left. We all know that the easy 90% is over. You might be able to automate some of that, but that last 10% is 90% of the work. So don't think that you're almost done. And really that last 10%, sometimes it's 150% of the work. And that also goes towards timing and planning the migration timeline. You may think it's gonna be quick and easy and dirty, or quick and easy to get done. You may tell your boss it's gonna be done very fast. I can get it done. Just leave yourself a little extra time. That last 10% will take you longer than you thought when you started. When you're first starting, right, and if you've thought about picking Postgres, you may have gone down a list. You may have gone online. And hey, Postgres is the most eventual open source database. It has all these great features. You can compare them up against Oracle. You can compare them against SQL Server, MySQL, anybody. We've got every feature you could want. We've got even more features. They're all up there. And even more features. And we just talked about how in 10.0 there's gonna be even better partitioning. So you see partitioning up there. It's yes, but there's a little asterisk up there. You gotta pay attention to those little asterisks because when you're migrating, you need to pay attention to the details. One little difference, yeah, the feature's there, but that little difference could kill your application. It could kill your business users. And knowing what those details are really matters. So for example, if you've been here yesterday and today, you've probably heard people talk about MVCC, the Postgres data storage. And your application developers, if they're not used to Postgres, they may not know about it. They may be writing their application to insert records and then update and update and update and update. And that's gonna kill you. You're gonna have huge bloat. You're gonna have huge vacuum backlogs. Your application's not gonna perform. So knowing that MVCC's in there, knowing how it works really is important. If you're coming from Oracle, if you've got Oracle stored procedures, you may be used to writing exception handling inside your stored procedure and that's great. But if you do exception handling in PLPG functions, you start burning transaction IDs. And if you've run a large database, if you've run a high volume database, you may have started to find transaction wrap around errors every now and then. Maybe your database doesn't start up and you need to go figure out why. Well, if you're burning extra transaction IDs every time you call a stored procedure, that's not gonna help. That's gonna make it worse. So knowing that that little difference is there can make a big difference. Okay, Oracle has a data type called timestamp with time zone. Postgres has a database called timestamp with time zone. But they're not the same. They're not identical. If you just convert your database over and just use that data type, it's gonna behave differently. The application may behave differently and your business users are gonna get a different result. Explaining to them, well, you know, I didn't know the right data type, that's not gonna go over very well. So you need to learn that difference. One of the big ones is thinking about coming from Oracle. Every numeric data field in Oracle is defined as a number. It's really flexible data type. You can define your scale, your precision, you can store integers, you can store floats. It's great. Postgres has a similar data type. Every numeric field in Postgres could be defined as a numeric data type. You can define your scale, your precision, you can store ints, you can store floats. You could just store everything in a numeric data type. But if you do that in Postgres, you might get 40% slower joins. So if you move a primary key, that's a number field in Oracle, over to a numeric field in Postgres, when you join on that, you might be 40% slower than if you had made it a native int. So really paying attention to that detail is gonna matter. And remember, when you're thinking about migrating, it's not just your everyday DBA job. It's not just tuning. It's not just running the database. This is something that you may do once in your career, a couple times in your career, but you're not doing it every single day. And so you may not have all of those battle hardened lessons, all of those things learned. And if you're trying to learn it on the job as you go the first time, you're gonna have some little bumps. If you're like to do things around the house, let's say you like to do a little bit of repair work or improvement projects, you might have been inspired by the excellent bacon wrapped cheeseburgers yesterday at the party. And you might decide that you want to put in a new grill in your backyard patio. Maybe you're sick of carrying propane tanks from the hardware store. So you say, hey, I'm just gonna go ahead and put in a natural gas line out to that backyard patio because what could possibly go wrong? You've done some electrical work. You've done some plumbing work. You put the paper towel under your kitchen sink drain to test to see if there are leaks. And you check back every day if there's a drip on the paper towel, you know that your plumbing work wasn't perfect. What could go wrong with a natural gas line? You just check for leaks. Well, you're gonna wake up in the morning and you're gonna wake up maybe a little early, right? And your house is on fire and that's not good. So if you haven't done natural gas lines before, don't do it the first time on your own house. And if you're converting your Oracle database and you're doing your number types and you get 40% slower joints, I guarantee you your boss is gonna be yelling at you. The executive management at your company is gonna be yelling at you and you better put on your firefighting gear because that's what you're gonna be doing for the next month of your life or six months of your life, right? Is fighting that fire. And none of us here today, none of us in the community, none of us doing our jobs. We don't wanna hear our boss or your boss come up and say Postgres is too slow. Postgres doesn't work. It's Postgres' fault, right? That's not what we want. We want the migrations to be successful. So make your migration successful. For all those reasons that we talked about earlier, save money, get features, save money, move to Postgres, but make your migration successful. Pay attention to the details, do your planning up front, do your testing, do your testing, do your testing, and really the experience matters, right? There's a lot of folks here that can help you with your migration. There's a lot of folks here that can help train you to be much more successful in your migration. Make sure you take advantage of those resources and don't be the guy that burns down your database and is Postgres a black guy. Thank you and enjoy the rest of the conference.