I think we should be ready to go, wherever's up first.
I'm still clipping.
Actually, I might have to hold this because I think the audio doesn't work that well in this
room.
So hold on a second.
All right.
So, hey everybody, my name is Ben, so I'm going to kick us off with this talk.
So yeah, like I said, myself, I'm going to talk first and talk a little bit about post
stress in my sequel and the whole theme of this next hour is kind of the differences in
the pros and cons and sort of where like cross-pollination between some of the concepts and architectures
of these two databases could help the other communities.
Who here uses post-gress on a regular basis or builds it?
Who here loves my sequel?
Okay, great.
So this is the perfect audience for this kind of talk.
The component and what I had proposed to talk about is titled what I miss about my
sequel, but I'm not just going to talk about my sequel or we're all going to be talking
about both of these wonderful databases, but the reason why I phrased it this way has to
do a little bit with sort of the background of both myself and kind of as a company I'm
with a planet scale and a lot of the background has to do with historically we're known
as a company that runs my sequel as well as the tests and who here's familiar with what
the test is less hands but we have some.
So this is essentially a charting and a scaling and acts as a proxy that sits in front of
my sequel for kind of helping with high-scale my sequel deployments, right?
And so we have a lot of experience throughout the company, like personally my first database
that I ever ran and operated was a my sequel database.
And so there's a lot of things where we have a lot of comfort with this, right?
But one of the things that probably a lot of people in this room recognize myself included
is that over the years postgres has become more and more widely used specifically being
adopted by like bigger companies, right?
Running very large high-scale instances of postgres and a lot of you have probably seen
graphs that look like this before.
Many of you have probably been to dvngens.com before.
And of course you can argue with how they're measuring it and you know, is this actually
accurately representing what the industry is doing, but both based on kind of some of the
data that you can collect as well as just some of the sense that I get from talking to
companies that are running these databases is that postgres is very clearly becoming
more and more widely adopted, right?
Even though my sequel obviously still powers much of the internet and much of what we do
every day.
So as a company, we started doing and running postgres for companies just this past year.
And we're also working on Niki, we have some of the maintainers here who will be talking
a little bit later, but about doing this in production for other companies too.
So it's an interesting perspective coming from someone who's very familiar with my sequel
and as a company very familiar with my sequel, this kind of enter into the postgres space
and see where they're maybe doing things better, but also where there's certain things
like I said.
I miss about my sequel where it has some more maturity and some nice things about it,
which is what we're going to talk about here.
So before I get into a couple of technical things, I want to talk about just why postgres.
And I'm sure throughout the room, we have different people that have different opinions
about why postgres is being adopted, why people choose postgres over my sequel or vice
first in different instances.
So I think one of the reasons and this is coming from my perspective and a lot of the things
that I've observed is just an increasing maturity, right?
If you look over the past decade or maybe a little bit more, the amount of features and
capabilities that have come to postgres have like expanded and in some sense almost like
caught up in some aspects to where my sequel is at, part of it too is the licensing, right?
The postgres license very easy for people to fork, build their own features out, right?
There's the extension ecosystem and just being able to sort of more quickly bring in
the interesting new technology.
So for example, one of my, I did a bunch of benchmarking recently on the postgres 18, like IOU
ring and async IOU support, right?
And this is something that I think is very cool that that was brought to postgres, or is
that something that isn't really as far to my knowledge apart of my sequel yet, right?
So the ability for the postgres community to kind of adopt some of these technologies
and bring them in has been really cool to see that like pace that the postgres contributions
come at.
For those of you who aren't that well versed in the my sequel or in the postgres ecosystem,
there's a huge number of extensions that allow it to kind of increase its capabilities
or perhaps paper over some of the weaknesses that postgres has relative to my sequel, right?
So if you need vector support, if you need kind of advanced geographic information
systems, PG vector, post GIS, there's things like PG squeeze and PG repack that help with
some of the table-blote issues of postgres.
So I think one of the reasons why it's been adopted is because even if you look at postgres
and say, well maybe it's missing certain things or it doesn't fully meet what I need
for my application, there's so many opportunities to build in exactly what you need, or
the other perspective that I have is as a company for example planet scale.
When we started offering postgres one of the things that we wanted to provide is like
a really detailed set of analytics, because this is what our customers are used to running
the test and we give them a lot of insights into like query performance and a lot of details
there.
So we built out a custom extension because postgres didn't provide these APIs to get all
of the query latency data that we needed out of the box and it was very easy for us to
add that in as a feature in postgres, right?
So the extension ecosystem and also you know this is maybe depending on who you are,
what your background is, not something that you're doing all the time as open source
contributors, but in my role I talk to a lot of small companies that are starting out
and they're choosing their text acts kind of what to build on from the ground up.
And if you go back in time maybe 10 or 15, 20 years, my SQL is basically the default choice
all the time, right?
Like that's kind of just what everybody used.
If you needed a relational database you were using my SQL, whereas the story has definitely
changed.
Where a lot of the default choices for what companies are building things on is mostly postgres,
right?
Unless people happen to have a lot of my SQL expertise, there is so much energy behind
the postgres community, which is why the last thing I put on here is also just vibes.
There's a lot of people that are not necessarily choosing it because they've done a
deep analysis of both databases, but simply because this is where what they're recommended,
right?
What other people that they know are using, where there happens to be expertise?
Okay, so getting into a little bit more of the technical side of things, what I've kind
of wanted to think about is like, okay, I look at these two databases.
And I see obviously if you drill into the details, there's hundreds of little differences
in terms of feature sets in terms of the settings and the capabilities of each, but you
can kind of buck it the different capabilities and pros and cons of each of these databases
into what I've picked as kind of six broad categories here.
And by the way, I love both of these databases.
So in doing this comparison and throughout some of the other speakers that are going to talk
about the differences between these two, it isn't about, well, one sucks and one is great.
It's just about being able to kind of expose what the strengths and weaknesses of these
are because it's very interesting to study.
So what I'm not going to talk about in the next seven minutes that I have is clustered indexes
versus the keep storage of postgres and replication because our other speakers are going
to take deeper dives into those after me, kind of kind of flowing into some deep dives
of those concepts.
So I want to focus on these other two, but I'm also not going to focus all that much
on indexing flexibility and extensibility.
And I'm sorry that red color is really hard to see on these slides.
And the reason why I'm not focusing on those is because the perspective of this talk
is mostly what I think my sequel has strengths of that I wish I could see more of in postgres.
And it's because for these other two, in my opinion, there's a lot more indexing flexibility
in postgres.
So it kind of has some advantages there and the extension ecosystem is very mature
in postgres.
So I want to focus on the process versus thread architecture, which probably a lot of you,
especially if you're familiar with these two databases, know about, and the storage engine.
And we're going to have to go through these quickly due to the time.
So who here's familiar with the differences between postgres process per connection architecture
and my sequel thread per connection architecture?
Is this something, I'm sure, good amount of people in the room are, but we have some less familiar.
So the way that postgres works is every time you open a connection to it, postgres is
forking a new process of postgres for that connection.
Versus in my sequel, we get a thread per connection and there's also like a thread
cache or thread pool that it can utilize.
So the in short without jumping into too much detail of it, every connection is heavier
weight in postgres.
Both the time that it takes to establish that connection as well as, you know, context
switching and the memory overheads and having their own virtual memory spaces per connection.
So this makes for, in some sense, the architecture is very nice and convenient in terms
of engineering and it's very nice isolation between connections.
But this also means that for really high concurrency databases, you can run into some
performance issues, right?
Because all of the context switching in the overhead of every connection is very high.
So one of the kind of challenges that I have observed a lot of companies run into,
is when you try to scale up postgres a single instance to be doing a really high number
of connections, there's issues with contention and performance there.
Whereas in my sequel, although you still can encounter some of those things that doesn't
become an issue until further along with a higher number of connections.
So the solution to this is generally connection pooling, right?
We've probably a lot of us, if you've operated databases, you've run some kind of connection
pooler, postgres, PG-Bouncer is a very popular option.
But this is something that we recommend that basically every connection on postgres, if
you can, should go through something like PG-Bouncer, right?
So that you can have, you don't have to re-establish connections with scram, which has
a lot of overhead, you can keep your set of direct connections to postgres that are very
fixed, controllable size, that you know, performs well based on whatever hardware you're
running the database on, and then you can run all connections through a pooler, right?
And so this is one of the things where, like I said, what do I miss about my sequel?
I like the way that my sequel handles high number of connection counts and the concurrency
control there, right?
And this is something too that this also ties in a little bit with how the storage engine
handles multi-version concurrency control and transactions, which will be the next talk
here.
And then the one other thing too that I'm going to talk about briefly is the storage engine.
So the cool thing that I really like about my sequel is the fact that it has the
sort of replaceable storage engines, right?
For those running OLTP workloads today in 2026, I almost just said 2025 there, but we're
not there anymore.
You know, DB is kind of the de facto standard, right?
That a lot of people are using, but there's been others in the past, there's things like
Brock's DB, or MyRox for doing, you know, LSM based like high right workload kind of
stuff.
And this is one of the things that I think has really made my sequel a lot more broadly
usable and applicable because a lot of companies can choose a storage engine that fits their
needs very well, right?
If you know you have a high right workload and you know, or maybe you have a mix of
kinds of workloads, you can actually be running all of the same very powerful database
engine like MySQL, but choose the storage engine that works right for the type of workload
that you're running.
So it really makes it very adaptable for scaling out different kinds of workloads, whereas
in Postgres, you don't quite have the same well, like there's the I'm going to go back
to this slide here.
I don't have a lot of details on the slide, but the way that it works is you're storing
all of your data in a heap file, which we're going to learn about a lot more in a second,
and sort of the base storage engine that you get doesn't have some of the niceties and
maturity of the storage engine of MySQL.
So some of the things that I like and I'm excited about in Postgres is that one, there's
a lot of extensions for sort of improving this, right?
Postgres is known as, you know, sometimes people with high right workloads and a lot
of churn on their tables, end up with a lot of table bloats, and there's extensions, like
PG repack, and PG squeeze to help with these kind of things.
But I'm also really excited about some new developments in Postgres storage engines like
OrioleDB.
Do we have anyone in the room who's working on OrioleDB or knows a good amount of what that
is?
I'll be curious to talk to you if you do, right here, okay?
Let's chat after.
But this is something that I think is really cool because it's kind of bringing some of
the ideas that I really like about sort of an undo-based log, MVCC model to Postgres,
and in my opinion, it's kind of a best of both world storage engine that's going to be
coming in the near future.
So this is, of course, it's not really about which tech wins or which tech loses, probably
not the best title there.
But the way that I like to think about this is like in all of these different categories,
what are the strengths and weaknesses of each of these databases?
And I say this because I think over the course of time as these two technologies continue
to evolve, we can kind of learn from the other ecosystems, right?
Things that Postgres does well, maybe can be carried over into my SQL going forward and
vice versa into Postgres.
And then we're going to get even deeper dives than a second here on Clustered Indexes
versus the heap and replication.
So I'm going to wrap up here and who might I think, Pep, you're going to go next.
So I'm going to hand it over to you.
Well, I'm Pep, hello, and a computer used to be somebody who made calculations.
But in the second half of the past century, that concept changed first to a device that is able
to do calculations, and later it moved to a device that is able to process data.
And then what happened is that the cost of the unit of processing went down while the
cost of storage, it went down, but not that fast.
And the capacity growth, we have computing the growth was a skyrocketing while storage
was growing, but not that much.
What this meant was that data replaced processing in terms of value.
It was the value of data was more than the value of processing.
And at that time, relational databases appeared.
With relational databases, three concepts appeared, like concurrent access, multiple users
access the same data at the same time.
We had transactions, so things changes in data were all or nothing, and we had the
capability to change multiple types of data at the same time.
And all these things had to be done in a consistent manner.
So we needed the ability to see a constant or a permanent thing that is changing at the
same time.
And the only way to implement this was to have a way to have multiple versions of the data.
So multiple multi-version concurrency control appeared.
We have multiple versions of the data.
If the transaction can fail, this means that at least we need two versions, one with the
new version of the data and one with the old.
But as we also need to keep consistency, we need to have not two but a lot of versions.
And we don't know how many versions we will have because we don't know how long a transaction
will take.
And well, if we have a lot of versions of the data, we need to be able to know which
is the version that I am going to read.
And also, as we have a lot of versions, we need a way to be able to delete old versions
once we don't need them anymore.
So how is MBCC done in Postgres and in my skill, but actually in a DB, we need multiple
versions.
Where do we start the multiple versions?
In Postgres, we store the versions on the table itself.
So here we have the table and we have version 1, version 2, version 3, version 5.
In DB, this is different.
On the table, we just have the last version.
All the other versions are stored in the undo, which is the dedicated storage.
So here we have the first difference in Postgres, the versions of the row are in the
heap in the DB, they are in the heap, well, in the cluster index and then in the undo.
So we have multiple versions, but how we can identify which is the version we should see.
We need to assign an identifier to each transaction and then use this identifier to mark the
rows, and this way we will be able to know who did each of the changes and to start
this information, we will start in the row itself.
In DB, we have in the metadata, we have the identifier of the transaction, then we have
the row pointer that points to the old version of the row, and we have some additional
flux that we will use, for example, to know if our row has been actually deleted.
We have some more metadata for the purpose of this presentation.
We don't need this, and also the rows, it doesn't matter if they are in the cluster
index or in the undo segment, we have more or less the same metadata.
And the fact that we have a pointer between rows, when we find a row in the cluster
index, it will point to the old versions in the undo, and in the undo will find a row
that points to a previous version, and then a pointer to a previous version.
Okay, okay, it's gone, hello, hello, can you give me?
Okay, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you,
Thank you, thank you, thank you, thank you, thank you, thank you you, thank you, thank you, thank you for being safe looks, thank you, thank you you were nice, I love seeing you, thank you so much, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you thank you, thank you
In order to kill has been out here.
1-2-1-2.
I'll just go 1-2-1-2.
1-2-1-2.
1-2-1-2-1-2.
1-2-1-2.
1-2-1-2-1-2.
1-2-3-4-5-6-7-8-9-1-2-1-2-1-2.
1-2.
1-1-1-2-2-2.
1-2-1-2.
3-草 search for a map.
3-1-2-1-2.
1-2-3-3-1-2-3-7-3-7-4-2-2-1-2-3-3.
1-2-1-2-1-1-1-1-1-1-1-2-1-1-1-1-1-1-1-1-1-1.
I mean, this works, right?
What?
Okay,
So my fatt
One, two, one, two.
One, two, one, two, one, two, one, two, one, two.
Yeah.
One-One-one-one-two-two-two-two-two-two.
One-two-one-two-one-two.
I mean it shirts here so they are just so beautiful here and here you can go and there.
Yeah!
One-one-one-one-two-two.
Yeah, yeah, we can show it.
Let's show it.
So the situation is that it is record.
You
See there? Give me a sec.
I have DX, no
I have a license
Nick, you all, Nesh, Testing the mic.
This, the, check...
calling info, report.
Okay, This is not right.
Myua, myua, stop!
Check, check...
As we could know, it was a new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new
new and new, new, new, new, new, new, new, new, new, new, new, new, new, new, new new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, new, anE, new, new
Hello, okay, my name is Pepp, and I'm sorry.
As I was saying, we have a metadata in it row, so we have the session identifier, the row
back pointer that points to all the versions of the row, and then we have some flags.
What we have here is a chain progression, so row, version 5 points to version 4,
then version 4 to 3, 3 to 2, and 2 to 1, okay.
In post-grace, we have also metadata, but we have some additional fields.
We have the X-Men, and this is the X-Men identifier, the transaction that created that row version,
okay.
Then we have the X-Max, that identifies the transaction that made that version obsolete.
So if X-Max is empty, this means there are no new versions.
We have the CTAD, that points to the next version, not to the previous, okay.
And we have something additional called visibility bits.
We will see them later, and the way progress works is that version 1 points to version 2,
then version 2, version 3, and version 3 to version 4, and then version 4 to version 5.
So here the differences are all versions points to new versions, while in the B, new versions point to all versions,
and we have differences in the metadata we have.
And also, we restore everything.
If a row is rolled back, we have that row stored in the table, while in the B,
we always store active or committed rows.
So when we undo our transaction, we remove all the traces of that transaction.
So white, so white here, okay.
Well, the problem that we have, this is like that missing, I don't know why.
Okay, no, it's something happened with the order of the whites.
So the problem is that if we know the ideas of the transactions, that's not enough.
Because we also need to know if that transaction was committed or is simply active.
So if I find the row, that row may be just belonging to an active transaction,
and could be a row that are committed to handle this, what we use is something called as nations.
What doesn't option brings us is a way to identify if a row should be visible or not.
And this option is created at the beginning of the transaction or the statement.
These depends on the isolation level we are running.
So if we are running, repeat our read, then this option will be created at the beginning of the transaction.
If we are running in written method, then we have to create a snapshot on each statement we will run.
And what we have in the transaction is a way to identify transactions in the past transactions that are active,
and also transactions in the future.
Because it can happen that while I am running at the transaction or the transaction to start after the beginning of the transaction.
How this is done in Portuguese, in Portuguese, the snapshot, because it has the expertise that identifies, let's say, the frontier for the future,
or everything after that value is in the future.
We have to examine that identifies the past everything here is for sure done,
and then we have a list of active transactions.
And we have something very important because as in Portuguese, we have stored data of a transaction that has the transactions that have been rolled back.
We need a way to know if a transaction, the outcome of a transaction.
So this is in the commit work.
So we have the transaction timeline, and also a way to know the outcome of a transaction.
Does this mean that for every row, I need to, I find a row, but I need to know the outcome of that transaction.
So this means I look at the row, and I have to go to the select, for another row, I look at the row, then I have to go to the select.
There's a way to avoid this is using the way to avoid this is using the visibility dips.
So when I read a row, if I go to the select, and I see that the row is visible, I update the visibility bits of that row.
So this means that in Portuguese, reads can write.
This page makes the page dirty, so that page will be flush, but it's not written in the wall files.
So if you change the visibility bit and the data is precious, that change will be lost.
But it's not important because at the end of the day, it's just something that you get by looking at this law.
In anatomy, there is quite similar, but we don't have this law, because as I said before, we just get data of active and committed transaction.
And the visibility bits are complex, there are a few rules here.
It's just to make the math.
So in postures, I also something important.
Transaction IDs is that every transaction has an idea sign.
Actually, this is not completely true.
We assign IDs when the transaction performs a change.
While we don't have a change, we don't need to assign an idea.
So we create a snapshot that gives us a view of the database, but without an actual transaction ID.
That transaction ID will be assigned when we perform a row.
Postures uses a snapshot and select plus additional bit later, like the visibility bits.
While in a DB, you just read the views, that's a name of a snapshot.
And the current transaction ID, or zero, if it hasn't been generated.
So thank you very much, questions.
No. Sorry, I did not understand.
Okay, it looks like I'm losing this light.
They're blind, I don't know why.
Okay, so I'll explain.
So it's great.
We know that the changes were done and all the stuff.
And we have a lot of versions, but we need to be able to clean those versions.
Because otherwise, we will run out of a space.
Okay, in order to know this, we have to waste to do it.
In a DB, what we have is the parts process.
What the parts process does is cleaning, but how can we clean?
In order to be able to clean, we assign another number to the transaction.
And that number is assigned when the transaction is committed.
That number is the transaction number.
Okay, so when we commit a transaction, we assign that number.
And we store in something called the history list, a pointer to the metadata of the transaction.
And this information will be used.
The information with data that we have in the review to find all the versions generated by the transaction.
And to delete them if they are not needed by any other transaction.
Okay, so we need to jar a little bit looking at what's running and the past of the transaction.
Unfortunately, this is done using vacuum.
What vacuum does is looking at the whole table to find the rows that are not visible anymore.
So this would be extremely expensive because you would need to scan the heap every time.
So to avoid doing this, there's something called the visibility map.
The visibility map is a map, a bit map of pages with two bits.
But here we will talk mostly about the first one.
The first one says if that page has all the rows visible.
So when I change a page, I place that bit on off.
So I said, no, all the rows are not visible.
And after some time, vacuum will look at the page.
We'll look at all the rows.
And if all the rows can be made visible, it will say all visible.
And it also will clean all the versions of the row.
And something that vacuum does is also freezing rows.
But there is beyond the scope of this presentation.
So the final difference is that postgres cleans the rows using vacuum.
And the formation of the visibility map.
While the visibility cleans all versions using the history list.
I'm not sure.
We'll try to keep schedule in time.
There will not be time for it.
All right.
We are rolling it in Shlomi.
We're with Planet Scale.
We're both maintainers for VTests.
It's a CNCF graduated project.
A shot in front for my skill.
And we're also both working on Nike,
which is a shot in framework for Postgres.
So we're both working on all stuff,
replication, streaming, schema changes, schema tracking, etc.
And today we'd like to discuss the design decisions behind logical
replication for both Postgres and my skill.
And how those design decisions affect you the users of logical
replication.
So we'll have the room here is very familiar with Postgres.
Half the room is very familiar with my skill.
Let's start with a very succinct and high level overview of logical
replication in both.
With my skill, you have a primary server.
And as you write to the primary server,
it generates vine riddles, which is something apart from what you may know
as the transaction log.
And it's essentially the change log of anything that changes within that
database.
So that includes not only every insert delete update,
but also like any time you add a user or drop a table, etc.
A replica connects to the primary.
And through replication protocol asks for copies of those binary
log events and stores them locally in a temporary relay log.
And then when when able to processes through the relay log,
reads the events and replays it, replays them.
It literally replays them.
When it sees a drop table, it applies that drop table.
When it sees an insert, it goes ahead and inserts a row.
In doing so, it generates its own binary log,
and is able to then stream those changes downstream.
So my skill replication is natively logical.
Right? Every binary log is really every binary log event
is really at change to the database.
The other distinction here is that the binary log always exists.
It's a pair configuration, but really it always exists.
And independently of any client, any replica, how many replicas.
There's the binary log, it's always there.
Postgres works very differently.
So the process primary writes wall entries.
Those wall entries are binary snippets that represent the aftermath of the change.
The replica pulls those wall changes,
writes them down in the wall path,
and then when able, according to a replication log,
goes ahead and applies them.
But differently from my skill, it does not replay them.
It just uses those binary snippets,
puts them in place or to speak.
Right? It's not necessarily aware that,
okay, this is dropping a table, this is insert in a row.
This replication mechanism is really physical.
This is not logical application.
In order to enable logical replication,
you will need to configure wall level to logical,
which will supplement or decorate those wall entries
with the necessary information for logical replication.
Among which one important aspect is kind of coupling
between the wall events and the system catalog.
So, now that we have an overview of both,
let's look at a few aspects in how the tool differ.
So starting with the content, as we've pointed out,
my skill, binary logs just include everything.
When you subscribe, let's say you run a CDC,
or you just interested in the change.
When you subscribe to my skill changes,
you connect as a replica,
and you start getting all the events.
Everything is there.
Sometimes more than what you bargained for.
Most of the time you're interested in a small aspect of those events.
Whereas in Postgres, you create a logical slot.
You give it a name.
You are a very specific subscriber for those changes.
And what you're getting is almost solely a table that it changes.
Insert the leads updates and an occasional relation message
that just describes to you what the table looks like
that those changes apply to it.
Next up is streaming.
So, with my skill, you just connect,
let's say, again, you want to run CDC.
You just connect as a replica.
You're using the standard my skill replication protocol.
The magical server, the primary,
it doesn't care that you're not a real my skill replica.
And what it is that you're going to do with the information.
Login and password, whatever,
authentication, you connect using the my skill protocol.
And the primary is happy to start streaming those binary logs to you.
So, and with Postgres again,
you need to create that slot.
And then Postgres starts standing.
You need to listen on the logical replication protocol
to start capturing those events.
So, before I go forward,
I want to say one of the lens that we are looking for,
looking through is witness.
So, I don't think we're done great PR with witness.
Not doing you can know it.
But it powers all your slack messages,
it powers GitHub issues,
PRs, cursors,
closed data, in witness.
Uber has been adopting it now.
So, it works at massive scale,
very high availability,
five seconds of downtime,
causes an incident.
We get woken up.
So, for the Postgres protocol,
the logical replication protocol is
fantastic for a lot of users.
So, when you want to do a CDC,
like change in a capture,
you typically want the existing data first
and then you want to stream all the changes.
So, Postgres has just a protocol that does it.
You can just copy it automatically.
No changes needed.
Whereas when you work with my sequel,
it's slightly different.
You need to create your own snapshot first.
You get the consistent GT idea at that point.
And then you start streaming.
That's why the star is here,
that for us when we are building the sharing frame
or some of these things become a problem,
which we don't see in my sequel.
So, we'll talk about that here.
But when we do create a slot,
are you postgres?
We're creating it in the primary.
We get a snapshot.
And the nice thing is that you can export the snapshot.
We can use it in your own transaction and do the copy from there.
It's happened in the last couple of versions,
but in general, you need to keep updating the slot
on the primary as you read it.
And that has an implication on wall retention
and as well as vacuuming of old tuples
that are held by the snapshot.
So, badly behaved clients can cause a huge problem in postgres.
So, same, this is related to the issue of how it connects.
So, the client's can switch to the primary and replica
that is no difference.
And as long as you can, the bin logs are available.
Whereas in postgres, since we have
20, you can actually stream from a replica.
Your concept of failure was lots of great.
But you still need to update the primary.
So, to make sure that the wall,
you tell the primary that I've read up to this point
and can free up the wall.
So, there is a tighter coupling with the physical replication,
which affects your data.
And this is a more technical detail where
the mechanism of slot synchronization
between the primary and the standby.
Are a synchronous.
And that for us causes a lot of h cases
when we are dealing with, you know,
we want to deal with replica coming up
and primary going down within seconds.
Which normally is not a problem for most people.
But when we are dealing with the level of scale,
we are talking about this becomes a issue.
The retention is entirely decided by the server
in case of my cycle.
It can just boys the bin logs.
Of course, if the client needs that bin log,
we have to start from scratch.
But on postgres, because the coupling wall
can get retained a lot, there is a break glass of functionality.
So, it is good at least.
Make sure that your postgres does not crash
because of lack of this space.
But there is a shorter period where
a slot needs to respond.
And the slot needs to keep updating everything.
So, in terms of failovers, as well.
So, the same, again, the same design
also helps postgres with failovers.
You can always failover if you are
streaming from primary.
You can continue from the new replica.
Much more easily than it is possible.
PV17, which just came out end of 244.
If you the primary went down, you have to restart.
So, now with failovers logs,
it is much better for most users.
At our scale, we have a little bit of edge case issues
where we care for about orchestration there.
So, summary, I think logical application
was native for my cycle.
Much longer, so it is a lot more stable.
In the fact that the client state is the client,
it is not effector server as much.
It makes a big difference.
logical application is fairly new.
It is a failover support slot of a company.
But, on the other hand, a very vibrant
community working, logical application
getting a lot of attention in the last few sessions.
And, last few are uses already sequences,
which is not replicated.
It is going to come in 19.
We have told maybe the ideal application might come sooner.
So, in that sense, it is improving.
But, so, I hope, at given,
we all given,
flavor of what the differences are.
With respect to logical application.
Thank you very much.