[MUSIC PLAYING] Hey, everybody. My name is Rick Schiller. I'm a senior product manager at Quest Software. I've been at Quest Software for, jeez, coming up on 24 years. So I've been around the block a few times here and seen a lot of things changing in the IT space and in the customer base that we speak with. I'm currently the product manager for SharePlex, which is our database replication product. And I'm here to talk with you guys today about Postgres.
Also joining us is Mark Gowdy. Mark, do you want to introduce yourself?
Yeah. Hey, everybody. Mark Gowdy. I lead our technical consultants here at Quest Software. Like Rick, I've been around the block a few times and coming on 22 years, so just a little bit behind Rick when it comes to working in this space, supporting IT applications and databases.
Thanks, Mark. Yeah. I've worked with you a long time, Mark.
Yeah.
OK. So one of my favorite things that I do as a product manager is I get to talk to customers about things that they're doing. And, you know, Mark, I don't know if you know this, but Postgres is very cool these days. Did you know that?
I did, but you tell me why is it so cool right now, Rick. I'm curious.
Well, let's start with who's saying it's cool. First off, DB-Engines gave it their database of the year 2023. And also, yeah, that's a pretty big deal. Also Stack Overflow, right? So the Stack Overflow developer community. Most used, most desired database. I certainly have customers telling me it's cool as well. So, you know, I think this is a great example of a shiny new kid on the block. Wouldn't you say, Mark?
Rick, I'm not sure I agree with you on that one. Shiny and new? Shiny, yes, but new? Postgres has been around just about as long as you and I have been doing this.
[CHUCKLES] Yeah, I know. That was a pretty ridiculous statement designed to create controversy. And there's actually not much controversy at all about that. Been around 25-plus years. Way longer than us, for sure. In sort of its current incarnation, though, 20-some years, with big, big organizations behind it-- Fujitsu, EDB, Crunchy Data.
Of course, now all the cloud vendors have jumped in on this. You know, Fujitsu, EDB, Crunchy-- there are a lot of contributors to this community who are building this product. And I know you and I were talking about this, and you were just mentioning the changes you've seen in the product itself over time.
Yeah, for sure, and this is the really cool thing. When you think about Postgres, it's had a regular release schedule, you know, multiple releases throughout the year, multiple major releases. And what we've seen is over the last 5 to 10 years Postgres is getting closer to the capabilities that solutions like Oracle and SQL Server offer natively. And in some situations, they're actually creating capabilities that go beyond what Oracle and SQL Server do.
So it's giving developers and DBAs greater alternatives to support their mission-critical application needs.
Yeah, it's got really a pretty amazing developer community behind it. You know, those people all deserve kudos for the work that they've been doing. So yeah, I mean, clearly Postgres has been developing for a long time. And if you look at DB-Engines and their rankings-- and, you know, I know there's a variety of ways you could rank this. But this is a pretty reasonable source for looking at it. You can see that it's had just steady growth.
It hit its tipping point somewhere back in the past, where people started using this much more often. So, you know, I don't know, Mark. I'm kind of curious. You know, when and why do you think it became cool? Probably not possible to pinpoint a specific thing. But what are some of the things you--
Yeah. I think there's a few things, I think, just around adding those features that become mission-critical that allow them to consider stepping away from traditional database technologies like Oracle and SQL Server. And so, you know, over the years, adding things like logical replication, support for additional languages and platforms, adding things like additional tightening of security-- those features really allow you to play in the enterprise sandbox.
Rick, what about you? You've probably spoken to a few customers about those features that become critical from a Postgres point of view.
You know, it's funny. I hear less about features than I hear about their drive to use it, which is Oracle cost reduction. So, you know, there's this Reddit thread. It's awesome. Like, when did Postgres become cool, or when was it hot? And I think the most upvoted one was something along the lines of when you got your Oracle or SQL Server bill. Right? Like, the cost of doing that.
Now, as a company, we're kind of biased. We come mostly from the Oracle space. So, you know, I have this lens through which I see the world that doesn't cover the whole Postgres community. But certain for me, the thing I hear about is that people trust that it's far enough along that it's robust enough that it could do the basic job of an RDBMS and that they can consider using it for those types of workloads that they might not have before. Right? Those enterprises.
Yeah, and the licensing is definitely key. And having that open-source methodology and the ability to contribute to the source is really critical for a lot of organizations out there driving the direction of the product. And that's often difficult when you're dealing with a large organization like Oracle or Microsoft. You know, changing the direction of product is really difficult. But if you can do that through open-source platforms, then that does get a lot of interest from developers.
There's an interesting no lock-in thing here, right? Because this is community-driven. Now, most of the organizations that I interact with are using Postgres of some flavor that's delivered or packaged up by some other vendor or, you know-- so like the database as a service on Azure, or AWS, or EnterpriseDB. But the reality is you're not locked in to any of those as long. As they're all Postgres-compliant, you could theoretically move between any of those.
And the other thing is you can actually choose the flavor, depending on the needs of the application.
Sure.
That's, again, very difficult to do when you're just looking at single flavors of Oracle or SQL Server. With Postgres, there may be variants that are better for different types of application processing.
Yeah. So there's this interesting idea. I don't know if I've talked with you about this, but Postgres and tipping points. And it's pretty clear that Postgres hit a tipping point sometime back in the past. Right? You don't end up being database engine in the year-- database in the year. And by the way, I didn't actually mention this. I didn't say this clearly.
They won it three other times as well. So there's something like four out of the last seven years they've been database of the year. So again, this is no overnight success. They hit a tipping point, but there can be all sorts of tipping points. And I would argue, at least based upon the customers that I'm talking with, that there's kind of another sort of tipping point that I can't tell if we've hit it entirely or we're right on the cusp of that.
But I would argue there's another tipping point of using Postgres in your most mission-critical applications. So for me and, again, for us coming from where we're largely an Oracle company, this usually means the biggest enterprise is saying can I reduce my Oracle cost by moving some of my-- well, there's a variety of ways you can do that. Right? And we can talk about this, but it's really am I going to trust my mission critical workloads on Postgres?
And I think we're hitting the tipping point because, you know, I have at least a few customers that are doing that. And I want to say one more thing because I can tell, Mark, you want to chime in here as well. When I look at the commercial vendors who provide Postgres-- funny-- in at least three of them in the name is "enterprise." Enterprise Postgres.
They're after the same thing that we're seeing and wanting to see, which is enterprises adopting it for their most mission-critical sorts of things. You and I have talked a little bit about this idea of tipping points. What do you think about that idea?
Yeah. This is something I've seen through customer conversations but also through conversations with developers, DBAs, other vendors at trade shows over the last probably four or five years I've been-- well, last four years, where we have gone to various Postgres-themed shows. And we've seen those grow. We've seen those get much larger with a wider remit of customer types and profiles attending those shows, whereas in the initial stages it was very developer-driven.
It was a lot of DBAs, developers coming, talking about these cool little applications that we're building to building net new. But the tenor of those conversations have changed. The presentations are about migrating from Oracle to Postgres, migrating from SQL Server to Postgres, you know, scaling large application workloads through Postgres, high-availability disaster recovery, replication.
Those are topics that you get when you're talking about enterprise-class applications. And we've seen that, and all of the conversations we have now are at that level. They're how do I do these things, how do I move mission-critical applications over, as well as how do I build net-new, mission-critical applications, and how do I bring them all together. So really seeing that excitement over the last four years in particular.
Yeah. You know, I'm guessing that at least some of this-- disruption, right? When change comes, people have to do some reevaluations. Right? So everybody's always undergoing these modernization initiatives, cloud certainly. You know, as people are thinking about, well, how am I going to move my workloads from on premises into the cloud, it creates these opportunities to rethink how you're going to do things.
And at most-- I wouldn't say every customer I talk to but greater than 50% for sure. Probably more like 75. There's some Postgres happening in there within their world. Now, whether that's an individual DBA in a unit or whether we're talking with somebody higher up working on an architecture of how we're going to refactor and rebuild this whole thing over three to five years, there's some talk of Postgres.
So, you know, I want to talk a bit more specifically about the types of use cases we're seeing. And again, you know, we have sort of a specific view into the market. We don't see all of the Postgres. We end up talking with customers who are largely Oracle-based and looking to start implementing Postgres. And I tend to see there are these sort of levels of complexity or risk associated with doing that.
Almost all of them are coming from perspective of Oracle cost reduction. And I'm not meaning to bag on Oracle. We deal with Oracle all the time. You know, we're partners of theirs. We support their databases with lots of things. It's amazing technology. I just see as companies are getting squeezed to do more with less, they're looking for ways to do that.
So, you know, what I see is the first thing. And, you know, I'm sure the other Postgres vendors would tell you the same thing. The first thing you tend to see is people building new apps on Postgres. Oh, we're going to do something new on it. For us in the data replication space, when we're starting to hear about those, [INAUDIBLE] that in the sense of they're wanting to use Postgres, but they need some data from Oracle. Right?
So it's like we're going to build a new application on top of-- you know, it's going to have some of its own data, but it's also going to have data from some other system that's Oracle. So we get out. We get called in for replication scenarios where they're going to have, you know, real-time data movement from Oracle over to Postgres to build out some new application.
I went and visited Korea and Japan last year, and neither one of those are thought of as particularly rapidly moving technology spaces. Right? They tend to hang back a little bit. And I certainly saw this use case. A lot of interest in this one. I'm going to build a new app. I'm going to use Azure or AWS to do it as a database as a service, but I need Oracle data.
So that's one of the cases. I know, Mark, you've dealt with a couple other customers that were doing something similar, I guess you could argue. But reporting is kind of in a sense this way. Can you talk about that at all? For sure. It's funny because I remember you and I had this conversation probably about three years ago, where we were talking about the rise of Postgres. And you and I, I think, disagree slightly on the applications that customers were doing. And both were correct. We were both correct, but what we saw at that time was customers were just doing small non-production applications, net-new, non-critical applications, and occasionally taking some Oracle footprints and moving it to Postgres for reporting.
So you're offloading your reporting to Postgres, and that has just changed. As you said, we're seeing customers design new applications, move wholesale, and migrate their Oracle databases, especially those that have, you know, fewer amounts of PL/SQL, Oracle PL/SQL. They're moving those applications entirely over to Postgres. Sometimes they're doing that within a very short window of time, so the needs are changing quite rapidly.
Yeah. That's kind of like the second level of risk, right? So you've got this new application, and/or I'm going to replace a reporting server. They can kind of be considered the same thing, I guess, where we've got a medical analytics company that's doing that Oracle to Postgres. And then they're building their-- you know, they've been using it as a reporting server, but it's really kind of an analytics thing. So they're building all sorts of things on top of it.
To the next level of risk, which is I'm actually going to bite this off for some of my Oracle databases. Right? Those things maybe that are not as mission-critical. I mean, you called out a pretty important point about PL/SQL. You know, the amount and type of PL/SQL can be a challenging part of that migration. If you're really only using it as a data store, it's a pretty easy transition.
If you're dealing with more PL/SQL, then you're talking about maybe some application refactoring, some rewriting of things.
And we've seen that get easier as well over the last couple of releases from Postgres, with additional add-on enhancements. That work is becoming less onerous. moving from a heavy PL/SQL environment in Oracle to Postgres still requires work, as you said, but is getting easier for sure.
Yeah. And I don't necessarily want to favor any Postgres vendors over any other ones because, you know, we work with all of them. But some of them are building in more capabilities to make it even more compatible with Oracle as well. So we see those. The craziest thing and the thing that I'm most excited about is what we were talking about a little while ago, is the tipping point where somebody says, "No. I'm going all in on this, and I'm going to replace all or as much of my Oracle as possible."
This is the true enterprise-type deployments where the entire business is built on this technology. And, you know, we have a few enormous customers. I'm not at liberty to talk about who they are but doing this right now. Right? They're looking at how do I reinvent this. I've got one that's, you know, really quite far down this road. And, boy, I wish I could have this person on.
I was just talking with them yesterday, and they told me they're a lot of the way through their project and that they couldn't have done it without us. So the reason being they couldn't have done it without us in this particular case is because, you know, they have this massively mission-critical environment. It has active-active nodes all over the place.
They have, you know, this interconnected web of replication relationships between a variety of databases and applications that are all sort of interoperating to create this larger thing. So, you know, the types of capabilities that these biggest customers are talking to me about are the ability to do active-active replication. So, you know, really meaning can I have these distributed Postgres databases across regions that we can keep up to date with SharePlex so they can have multi-write nodes, replication to other platforms.
So especially like if you're doing this Oracle move, there's this interoperability back with Oracle. Maybe if you're looking to refactor or even all the way up and into including active-active Oracle Postgres that lets people do this super dynamic risk reduction with, you know, sort of a throttling load balancer in front of it. Right? Let me push a little bit of my traffic over to this new Postgres thing and let SharePlex in the background keep them up to date so they can really start seeing how this change is working for them.
Replication to other platforms too, right? So they also want to get their data to Kafka or Snowflake. But these are the customers that I think we're approaching this tipping point on. I mean, I see people talking about doing it. I know I guess I should step back a minute and say I've heard people talk about doing this say, "I'm going to replace my Oracle with Postgres."
I've been hearing about this for five-plus years, and I saw little pockets of it on the smaller stuff. Now I feel like I'm seeing it for sure at some customers. And I'm wondering if we've hit that tipping point yet.
I definitely think we have. I think we're seeing this, as I said at the Postgres shows, where that is a topic of conversation that the people attending are in the Fortune 500, the Fortune 100, and they are looking at Postgres as a legitimate replacement for other non-open-source relational databases for their mission-critical applications. And we're seeing that. The other thing I just wanted to touch on, Rick-- you touched on this-- is with SharePlex we have been in this database replication space for 26 years this year. And we understand this implicitly.
We are experts in moving data from one platform to another, whether that's Oracle to Oracle, Postgres to Postgres, or combinations thereof. And the confidence in the solution like SharePlex allows people to make that move, you know, where the platforms may not yet be fully capable in doing those multi-active-active environments and architectures. In combination with a tool like SharePlex, they have that confidence.
Yeah. You know, it's funny because you and I have talked about this a bunch, how Postgres looks, you know, kind of similar to Oracle, this market, 25-some years ago. Right? People are pushing the boundaries of it, and they need to do things that the native technology inside of the database couldn't. So this is why we were invented, you know, back before the turn of the century because people were pushing the Oracle boundaries and they needed these replication-type capabilities.
We're seeing the same thing with the Postgres stuff, and that is a great point. There's 25 years of intellectual property built into SharePlex. A massive amount of trust built with Fortune 100 companies and supporting their most mission-critical. So seeing these types of customers make these moves, it's really pretty exciting. Really, it's market-shifting.
Yeah.
Yeah. Thanks for bringing that up. You know, I do want to make sure as I mention this here I don't make it sound like it's all fun and games. You know, it's a massively challenging product to undertake or project to undertake something like that, where you're going to take, you know, your most mission-critical business application and fundamentally change the platform on which it runs.
It's pretty scary, I think, for the leaders to make that leap. A lot of pressure on them to make that choice, but it's all work. It's stuff you can work through. You know, one of these customers I was talking with, as they've been working through it, they've been in contact with the developer community inside of Postgres, talking about things that they need and getting clarity on how things work because they've had to shift things in the way their application stack works to make it happen.
But they can do it, right? It's possible to do. Pretty exciting.
Sure is.
You know, I do just think I've been plugging a little bit SharePlex in here. You know, mostly, I've been trying to keep this as a conversation about what we see happening in the Postgres environment from our particular point of perspective. But I do just want to make sure everybody knows what we do, right? At Quest, well, we do a lot of things, but I'm the SharePlex product manager.
And what SharePlex does-- SharePlex is database replication. So at the core, database replication sounds pretty innocuous. You move data from one thing to another, but really I equate it to plumbing. It's a little like plumbing. Not super sexy, but when you get right down to it, it enables these amazing things to happen-- flexible architectures that you can build, these active-active, interconnected systems crossing platforms that are talking.
And so SharePlex, for 25-plus years, we've been doing this for Oracle. We've added Postgres a few years back as-- a few years. Boy, it might have only been-- I don't know-- 15 months ago, probably. We brought--
It was just over a year ago, Rick.
As a source. Yeah.
As a source. Yeah.
Time flies. We've had it as a target for a long time, but we brought that to market at the request of these big customers that wanted to try to do these things. And they said, "We think we can move to Postgres if you can do the same things that you do for us on Oracle." So, you know, the primary use cases are replication from Oracle to Oracle or Oracle to Postgres.
In this case, since we're talking about Postgres, Oracle to Postgres to create interoperability sorts of scenarios, including and up to no-downtime migrations. So, you know, you always have this downtime associated with the data move. We can keep the systems in sync in the background. So we can queue up the changes, bring them up so that you don't have to take downtime on your primary system.
Also does a huge amount of risk reduction for you because you can start to test. You can create fallback scenarios. You can actually go all the way up to-- like, I started talking about this throttling load balancer, right? Where I'm going to put just a very small percentage of traffic to the new thing but keep the stuff in the background in Oracle up to date.
For the mission-critical deployments, we see active-active cross-region. Super important for those users. And then, you know, the basic things you need from any enterprise application like that is you're going to need to cross. You're going to need to get some cross-platform data out to your new things that you're building that aren't Postgres. Right? So through Kafka or Snowflake for your analytics projects.
And we did this. So we delivered the first release of this about 15 months ago. That was for Community Edition. We've since added all of the major database-as-a-service platforms. So, you know, covering Azure, Amazon, Google. We've been actually having some great engagement with Microsoft on Azure, SQL Postgres, Azure SQL database for Postgres.
And then what I also want to announce is that we have recently added our most-loved product feature. Mark, do you know what our most loved product feature is?
I do, but I think you should tell it, Rick, because it's so good.
It's the compare-repair feature, right? So people have always loved-- you know, that's actually a pretty critical part of all this if you're going to be replicating is how do I make sure that things are always in sync. Now, SharePlex does a lot of things in the background to ensure on the data that it's operating on that, those are in sync.
So before it makes any changes, it checks the values and makes sure that the records that will be operated on are in sync. But there can be out-of-syncs that happen that are hidden that you can't see. So compare-repair is the feature that enables customers to go through and validate their data that are at rest that we're not actively operating on to make sure that the systems are up in sync. So we're super excited about that.
I have a really great dev team. I know. Mark, you've seen-- I would say last year was probably one of the most productive development years we've had in SharePlex for over a decade. So, you know, I've been really excited about the output.
Yeah. You and I have been working on this product for many years. SharePlex, as I said, is 26 years old. The fact that we continue to innovate with a product that is 26 years old is astounding. And we're meeting our customers where they are on their journey and continuing to allow them to innovate. So, yeah, kudos to you and the dev team for making these things happen.
Yeah. It's actually been great talking with customers and being able to fulfill this and see it happen. So for those of you that are on this conference, I'm certainly looking forward to being able to help you. We care about this Postgres market. We think that there's a lot of value that people can get from Postgres. And if we can help you in that, we'd like to, as Mark said-- I love the way you said this-- meet you where you are.
Be happy to help you with anything related to this Postgres conversion.
Yeah. And we'll be at the Postgres conferences this year, Postgres conference, PG day, and a few other events. So feel free to reach out and say hi.
Awesome. Hey, Mark. Thanks. Thanks for joining.
Rick, it's always a pleasure, my friend.
Talk to you later.
[MUSIC PLAYING]