AWS Babelfish: The Elephant in the PostgreSQL Room?
postgresql.fund
postgresql.fund
This is true only to a degree: Adding new procedural languages is supported, but support for new query dialects (i.e. the main contact surface of most applications with an SQL RDBMS) is not currently a supported feature.
As mentioned in the psql-hackers thread from the article, currently the postgresql-specific parsed syntax tree is passed through many components, and to replace the syntax you'd have to alter and recompile the core application.
One of my fears. That unless we, as the PostgreSQL Community, do something about it, and embrace the efforts that AWS started doing and I hope will continue, it would effectively end up being a fork. And a fork with a collaboration on GitHub, which many would prefer to contribute to rather than current's Postgres contribution mechanism.
And if that's the case, I wonder if it could become the MariaDB, or the LibreOffice, of Postgres. I hope we will be able to do the best thing and have the contribution that Postgres is receiving integrated and merged into Postgres.
Personally, I think that the word "fork" has a lot of historical meaning in the world of Free and Open Source Software. To me, "fork" means that there is a "vote of no confidence" in the direction of the people who are making decisions about open source software. That clearly is not the case here. The PostgreSQL core team has a very good reputation of being collaborative, and thoughtful, in their work to make PostgreSQL the best database it can be for the community at large, and not build it to benefit any particular commercial interest.
Often software development happens on branches. These are experiments, not forks. Over time, good ideas are propagated, and grafted, between the branches. These are not "forks" to me.
I see this as a very open and collaborative approach. To announce such a big contribution to Postgres, and be it open sourced when published, is very welcome, and I believe one of the boosts, as I mentioned in the post, that Postgres needs.
I'm also convinced that Babelfish and PostgreSQL will be properly integrated, and this will be a great win. I consider it too a development branch more than a fork, which certainly has "no confidence" connotations. But there's still some worry that it would become one, one day, if there's no sufficient effort towards its integration --as the conversation that I wanted to spark here was almost non-existent up until recently.
This actually brings the topic of more explicitly branch development in Postgres, but it's a different story ;)
But the source code hasn't been published. As I said to you today on pgsq-hackers, that's why it hasn't been taken seriously - that's just how it works.
> But there's still some worry that it would become one, one day
Who are you attributing that concern to, exactly?
You're basically claiming that it will be a great opportunity. But you're also claiming that it might be an existential crisis. Do I have that right?
Have you considered the possibility that it might actually be neither of those two things?
And maybe that's just how it shouldn't. Technology moves fast, very fast. Markets do so. Users, you get it. Competing technologies, undeniably.
To delay a discussion for months just because the source is not published is in my opinion only reflecting on part of the opportunity/problem. I'm calling for an strategic discussion, which is higher level than a code-only, limited, partial analysis.
> Have you considered the possibility that it might actually be neither of those two things?
Sure thing, like anything in life, it may be neither. But what I know for sure is that a) we as the PostgreSQL Community need to mitigate risks and plan for them; b) leverage (or transform into!) opportunities as soon as we identify them.
There is practically no information about Babelfish available to analyze. You can currently request a preview of Babelfish if you have an AWS account, though I'm not aware of anyone having even that level of access. There is a single page placeholder on a Github.io that says "Babelfish for PostgreSQL will be available on Github in 2021".
And so I genuinely don't know what a strategic discussion really means here. How much can be decided about something based on a vague press release?
I'd also love to have more, architectural/design documents, the code itself, etc, and I'm sure they will be sooner than later released.
But that doesn't prevent us, as I said, to discuss the items I suggested above. They do not depend on the source code, at all.
And independently of this, there is already one thread on the -hackers mailing list that provides some information and proposes to introduce a technical improvement that not only would ease the Babelfish integration, but will also provide significant benefits for PostgreSQL itself, allowing for other protocols to come (including a potential v4 and an HTTP-based protocol): https://www.postgresql.org/message-id/CAGBW59d5SjLyJLt-jwNv%...
This isn't the sort of thing that is decided with blog posts, but personally I am glad to see there is interest in this project.
To indicate a non-collaborative fork, I usually use the term "hard-fork", which I know from the blockchain world, where it has a similar "vote of no confidence"/"we are starting our own project with new leadership" meaning.
When you look at something that has nothing to do with the Babelfish functionality but would absolutely help PostgreSQL, consider PHOT. PHOT (Partial HOT) is a great opportunity for PostgreSQL that Amazon is trying to give back. However, I wouldn't be surprised if the .Org community were to not accept the patch, the feature would end up in Babelfish. If that happens, we now have a viable fork which has 100% compatibility++.
AWS has enough scale to have its own gravity and will likely run development forward regardless of .org, it would be GREAT if .org could actively work to integrate where possible the open source options here.
I remember some early efforts of google to contribute wakelocks and other features to the linux kernel - so annoying when that was shot down and created a pretty significant split, and the commercial entity wasn't going to hold off on wakelocks because a subsystem maintainer didn't like it - so android starting going off into its own land.
Wakelocks also ended up proving a reasonable power management approach (despite complaints they didn't use existing linux mechanisms etc).
There was a big push ultimately to get wakelocks into mainline and drive some convergence.
https://babelfish-for-postgresql.github.io/babelfish-for-pos...
Can the title of this post be changed to remove "AWS" please?
If successful, Babelfish will grow a community, and work harmoniously as an extension of PostgreSQL. And including "AWS" in the brand of the project may hamper the efforts to build a community around it (in addition to complications of using a brand / trademark like "AWS" in an open-source project).
The TL;DR is: "AWS" is not part of the branding of Babelfish for PostgreSQL, and that is intentional. The reasons for this aren't about obscuring the origins or initial sponsorship of the work, but are rather about establishing a separate identity.
[1] https://www.jwz.org/blog/2016/10/they-live-and-the-secret-hi...
Thanks for the great work!
Oracle's SQL Developer is the worst IDE for databases I ever seen. Oracle DB doesn't support "TOP N" or "LIMIT N" notations and many other useful features...
I like SQL Server more than Oracle and Microsoft provides 2 good IDEs for it (SQL Management Studio and Azure Data Studio). But it has some bad limitations - you can't define ON ... CASCADE on more than one path. You also can't create CTEs with inserts/updates.
PostgreSQL doesn't have a good IDE out of the box. I heard that Azure Data Studio now support it, but didn't try it yet, because I already paid for a commercial IDE that supports PostgreSQL. PostgreSQL also doesn't have a good high availability tooling, but all major cloud providers do this for you. Considering that you get it for free, it is a much better choice than Oracle or SQL Server.
[1]: https://dbeaver.io/
but in all seriousness, I don't know.
Because yelling at the database server doesn't make it work better, and just makes uglier code.
Instead of those nonstandard notations Oracle supports SQL-standard notation OFFSET and FETCH clauses (Postgres supports both LIMIT/OFFSET and OFFSET/FETCH, but not TOP.) OFFSET/FETCH is, IIRC, slightly more powerful than the nonstandard ones.
In my opinion, this is the inevitable conclusion of Amazon's sudden increase in direct involvement in OSS projects. With cases like elastic search close in the rearview mirror (I know that there were reasons for this, but it was a start), It's hard not to come to this conclusion.
Once the Amazon tentacles have reached down into every major staple of the OSS economy, it's difficult to predict the end result, but one thing is for certain, it will benefit Amazon more than it benefits anyone else, lest Amazon breaks its promise to its shareholders.
Amazon has demonstrated a pattern of controversial vertical integration, by using internal analytics to determine which of their own merchants' products they should undermine. To believe they would not do the same thing in their largest and most important division would require tragic ignorance.
This is all just my opinion
"Embrace, extend, extinguish" has never been uttered in any conversation I've been part of at Amazon. It simply is not part of the philosophy, or culture. We obsess about customers, and customers do not like the things that they depend on, like open source software that they've built their business on, to be damaged.
Rather, they want to do more with open source software all the time. And many want to find ways to get off of software that is constraining them, or causing unplanned stress or surprises when their costs suddenly change due to arbitrary license changes.
The promise here is to customers, and customers tell us that community-led open source software development is better for them. And this is no surprise. As a software developer, and a long time FOSS advocate, I believe it too.
By listening attentively to customers, I believe we will continue to build a business that we, and our shareholders, will be proud to be a part of, and will provide long term growth.
I mean, your second and third paragraph could be the introduction to an internal presentation about "why we at Amazon should embrace, extend, and extinguish OSS". The things you listed are precisely why Amazon would want to destroy OSS, Because OSS is a threat to anyone offering proprietary software, and anyone who has built their empire on OSS will inevitably need to shift to proprietary software to retain relevance in a world where OSS software "eats the world" by, for instance, commoditizing the infrastructure layer...
In other words, just in time for AWS to become less relevant due to the enormous gains in open source infrastructure as a service tools, Amazon will swoop in and help to destroy the most useful parts of the open source economy.
It's easy to look at this with a naïve optimism and think "but these are the exact kinds of things that helped AWS grow to begin with", To which the obvious reply is "yes, at the bottom end, but Amazon has been focused on enterprise more and more over the past five years, and licensing agreements with other big tech companies have changed the offering and the prospects of future offerings". All you have to do is look at YouTube to see another example of this. YouTube built its user base on small contributors, but as soon as it reached a plateau it began to focus on the old guard, main stream media, Hollywood, etc., unfortunately for the little guys. This is the same pattern every company takes once they get big enough to play competitively with the big boys.
This is all, of course, only my opinion.
Based on my own experiences, including engaging in very helpful dialog with critics so far, I am not convinced that the same kind of anti-FOSS campaigns that we saw, with ample public evidence, from actors like Microsoft and SCO of the past, would be in the interest of Amazon or its customers. It would be the opposite.
But I think it is right, and it should be expected, to continue to scrutinize Amazon, like any other large organization. I try to judge based on actions and evidence, rather than what-if speculation.
We are not talking about internal corporate PR. Enron also had great set of values [1] that were preached to the employees. It's about the actions, not the words uttered.
You'll find elsewhere in the comments [1] that on actions, not words, I agree with you. "I try to judge based on actions and evidence, rather than what-if speculation."
But besides that, I don't think Microsoft engineers in their day to day work ever mention embrace, extend, extinguish. Amazon's motive is profit. They're darn good at it too as we've seen. But that's all it is. If in the process they destroy an OSS company, as they've done, they don't care, because now they have their source and no competition.
They certainly embrace and extend which is the very nature and purpose of Open Source software.
I'd say the trend for AWS is leaning "do not join". Anecdotal? Of course, but with enough stories it becomes a statistic and not an anomaly.
Like I said in my other comment in this thread, I'm sure that there are some teams that don't have a good culture but it also comes down to the individual in many cases. I guess it comes down to individual preferences, some folks really don't want to work at Google, others dislike Facebook, some don't like AWS, etc.. But at the end of the day, all of these companies still attract a ton of incredibly talented people and I personally don't see that trend ending soon.
Imo, Amazon is a special level of toxic and abusive and it shows by their reputation in the industry and how high their turnover is. That's what I mean by anomaly vs statistic. When thousands (tens of thousands?) of your former employees have horror stories, it starts to build a strong narrative than a few bad teams or a bad manager. Or you start to question if the ratio of bad teams is that high, what is wrong the the company as a whole?
Does it mean your experience at Amazon is wrong or incorrect? Absolutely not. But your experience isn't the norm.
I'm not trying to argue with you here, I've just had a quite few discussions in recent times with people who had very strong negative opinions about MSFT being a place for the lazy, Google being a place for the special snowflakes, Facebook being a place for the cultish, AWS being a place for those looking for a stepping stone in their career, etc....and I think that all of these companies actually are great places to work but there will always be a few percent who absolutely hated their time there.
Just filled with stories of people that felt extremely wronged. Are there stories of people that with terrible experiences at other companies? Of course. Are there people that have had good experiences at Amazon? Absolutely. Does anything like the above exist for any other company? Not that I can find.
That's crazy and really speaks to the difference. If you believe that Amazon is "just another tech company" in how they treat their employees, I'd probably say you're turning a bit of a blind eye.
Not trying to be pedantic here, but this thread was about AWS and not Amazon, so I will just reiterate that I can't personally comment on Amazon as a whole, I can only comment on AWS and I think most people would agree that AWS can be put into the same category as FB, MSFT, GOOG, etc. I have highlighted this distinction several times, but you seem to not want to engage in a conversation about AWS and rather discuss Amazon as a whole. That's fine, but as AWS and Amazon are really two different companies, you are then comparing apples to oranges and in that case you should compare Amazon to e.g. WalMart?
If you're telling me that in 1.5 months, a company of 1+ million people only generated two complaints from employees, then that does not at all support the point you are making that Amazon is terrible to work for. That is an astonishingly low complaint rate.
>Does anything like the above exist for any other company? Not that I can find.
Have you never heard of glassdoor? Blind? There are plenty of sites that have literally hundreds of times more complaints against tech companies than what is shown in the site you linked.
* How many hours/week do you spend at your work machine?
* How often is a sprint crunched; how often does the sprint manager exhort sprinters to complete the board?
* How many incidents/quarter does your team have? How often does an incident route through you?
* How many hours/quarter are you oncall/onduty?
* How often do you have anxiety on Sunday night about going to work on Monday?
The answers should be at most 40, rarely, 12, 60, and rarely. Ideally, they would be 20, never, 3, 120, and never. Note that we don't require less oncall; we require less stressful oncall.
It's great to see Postgres growing, but I often wonder why it isn't growing faster, especially when compared to MySQL. Without getting into a religious flame war, I'm curious what the HN thinks about that?
We're having scalability problems with our RDBMS, but it's something RDBMSs in general don't solve.
This not the only problem, but it is the most pernicious
Outside the context of db comparisons, and in relation to the specific case, if you don't have triggers/foreign keys on a given MySQL table, Gh-ost¹ solves the DDL locking issues.
Has been since MySQL 5.6 (released Feb `13).
¹=https://mysqlserverteam.com/mysql-8-0-innodb-now-supports-in...
²=https://dev.mysql.com/doc/refman/5.6/en/innodb-online-ddl-op...
For instance, suppose you have a query that requires a full table scan. In PostgreSQL, that query comes in and the DB starts the scan. Now, a second such query comes in. PostgreSQL notes “I’m on row 10,000” and continues running one single scan, sending results to both queries. When it reaches the end of the table, it marks the first query as complete, then goes back to the beginning of the table and starts scanning again, sending results to the second query up until it reaches row 10,000. Now the second query has seen every row in the table and it’s finished.
Now imagine 100 such queries arrive. Rather than doing 100 full table scans, PostgreSQL satisfies all of them concurrently, taking at most 2 full scans (assuming the 100th queries joins in on the very last row of the first scan).
PostgreSQL has a million such optimizations under its hood that make it happily chug away even when it’s getting slammed. You can vertically scale a single-instance PostgreSQL server a lot higher than many people would believe.
So does MySQL. Facebook, Google, and Percona have contributed many upstream patches to harden and improve MySQL over the years. MySQL also has much better observability to find issues causing problems, from index_statistics to hunting down individual queries causing locks.
I agree that Postgres is by far the better engineered product, but it's not necessarily the better RDBMS product because of that. MySQL is battle tested in a way that Postgres isn't (yet).
InnoDB had ranged from slightly faster to much slower than Postgres depending on exactly what you’re doing. Once you’re doing more than trivial queries the MySQL optimizer tends to fall apart, often in weird ways with arbitrary thresholds where performance goes from decent to terrible after a table grows by 5%.
Also, database/schema/tables is great when doing things like multi-tenancy where you split customers by schema (which also makes horizontal scaling super easy if needed).
For example, when you type quit instead of quitting it instead prints out that you must type a different command to quit
All of \q, quit, and exit work fine starting psql 11?
If I'd compare this to MySQL, where you must move tables one-by-one to another schema (nay database) with the new name to 'rename' your database [0], then I'm very happy with postgres' hierarchy structure.
[0] That is, if you're even allowed to, because if you have a trigger on your table, good luck renaming your database. See https://dev.mysql.com/doc/refman/8.0/en/rename-table.html
People don't need those white-label commodity cPanel or Plesk shared-hosting or VPS services to run SaaS applications anymore - it's far better for everyone[1] when they switch to a major cloud provider, namely AWS, Azure, GCP, etc.
I argue that most web/saas devs today grew up with - and tinkered-with - said white-label services: which means they got their experience with MySQL because it was part of the stock default configuration for all those web-host accounts: with PHP, maybe Perl, and many preinstalled web-applications like phpBB, Wordpress, Coppermine, phpNuke, and so on... and that's probably a solid 15+ years of commonplace web-hosting market saturation (thinking 2001 through 2016, with 2014 being the tipping-point for AWS/Az/GC being the home of SaaS).
You'd be in high-school age-range (14-18?) and get bored of simply running other peoples' programs on your web-space, and you saw these web-applications were written in PHP so you'd follow some series of online tutorials for PHP and when it inevitably leads to databases they assume you have MySQL - and MySQL (at the time) had not only the widest installbase, but also had a far more forgiving SQL engine than anyone else. While PostgreSQL was often only a few clicks away via quick installers built-in to cPanel/Plesk/etc, MySQL was a safer-bet by everyone involved.
...but those days are past: as a personal anecdote: at no-point in the past 10 years have I come across any "serious" PHP web-application software intended for private or on-prem usage since vBulletin or SVN.
[1]Except free-as-in-freedom software advocates...
If only postgres won the marketing battle back then...
Be glad they didn't - otherwise their support dept. would be buried under questions from web-hosting newbs.
Why?
There's Phabricator [0], which incidentally uses MySQL.
I feel the same way with Unix/Linux. At one point I was told that my organization may be migrating away from Linux, and redeploy everything under Windows. The management layer really couldn't understand that they would lose nearly every Linux admin on staff (that happened to also have deep understanding of their apps and infrastructure). "Why would someone have a problem with switching platforms -- we'll provide you the training" was their answer. Fortunately we were able to come up with a number of technical (and cost related) issues that the project was shot down.
Companies with large and complex db installations often need the complexity for various reasons that are difficult to escape, even if you're working on a green field project.
Of course if you don't need any of these additional tools or can't afford them, then yeah pg is a great choice.
Aside from the raw cost, the licensing model and cost considerations can drive design decisions. In my experience, most shops that use MSSQL do so because nobody on staff has experience with other databases.
If you're a small 2-5 person team, sure. But once dev payroll breaks $1M/yr, paying ~$100k for SQL Server doesn't seem so bad anymore.
I have yet to encounter a team that would rather have SQL Server than another developer given the explicit choice between the two (assuming easy migration, etc.).
I've only interacted with Analysis Services and Reporting Services for maybe five minutes, but the impression I was left with is that they're extremely clunky, even by Windows standards. I also remember a weird situation with SSL wildcard certificate configuration, where the interface said the configuration wasn't applied, but it actually was.
My client subcontracts this to a supposedly "expert DBA" shop, and they always seem to take ages to do what look like simple things on the surface. (I rarely if ever interact with them, so I don't know whether they're actually competent or not.)
They probably do if you have certain needs, but at lots of places they seem to be the basis for solutions that would be far less complicated (and maintainable with a far more common skillset) without them.
Tools like Airflow and Druid are just now getting to where those tools were in 2005 ... unfortunately those tools haven't done much since about 2015 when Azure became the new hotness.
IME, that “deep experience” often means “a very expensive support contract and internal technical staff who walk through decade+ out of date cargo cult rituals by rote without understanding the rationale and why it has been gone longer than they've been employed”.
DBAs and Engineers that know MySQL will always use MySQL. In corps MySQL is a safe choice (sadly).
CREATE PROCEDURE get_customer_and_orders
@id int
BEGIN
SELECT id, first_name, last_name, email, etc FROM customers WHERE id = @id;
SELECT id, store_id, created_at, etc FROM customer_orders WHERE customer_id = @id;
END
I think that features like this are why many businesses will stay on SQL Server. Also the high quality of tools for SQL Server that have no match in Postgres such as SQL Server Management Studio, SQL Server Data Tools, SQL Server Profiler, SQL Server Integration Services among many other such tools that are extremely well integrated.
That being said, haven’t some recent versions of Postgres added support for stored procedures or some variant? I’m curious if we’d seen any changes in performance if we experimented with switching over.
It's absolutely ridiculous to make a blanket statement about this very useful feature.
I've done the benchmarking on many applications of this tactic. It very often works better with multiple select statements. I'll certainly trust hard performance numbers against an ill conceived opinion any day.
Also the freetds guys hate it :) https://www.freetds.org/mars.html
(I am currently converting a MARS app explicitly so it never does utilizes this approach)
I personally LOVE pg over all other choices, but I've got some 5-year-old apps sitting on a little mysql DB and no intention to move them. Dbs are small, performance is good enough, cost of instances wouldn't be very different on PG, but cost of moving everything over is probably a week or two of work that would be pretty hard to justify given the current situation.
2. Companies looking for enterprise support don't see anyone as high profile as Microsoft, Oracle, and err, Oracle supporting Postgres.
(Whether ongoing interaction with Oracle is a net positive is of course debatable. At a previous company our only interaction with Oracle was them being inflexible and expensive that ultimate meant we had a Oracle DB on prem serving a AWS hosted service because it would have cost too much to put it in AWS. Note, this was many years ago, before AWS had a compatible offering, and apparently Oracle even have loosened up a bit here since.
We see some customers building new solutions on Postgresql, but for large setups, it’s still MariaDB/Galera or Oracle and there isn’t a big push to drop Oracle.
Lots of things are just half-baked and very clumsy in Postgres compared to MySQL (MariaDB).
When PostgreSQL would get a built-in replication tool would increase it's popularity a lot, but I guess the core team wants to focus on the DB, and management tools are left to the others to develop.
IMO replication is a core feature of a DBMS (like transactions or SQL support), the fact that you need to install obscure third-party tools to bring Postgres into the modern age is bonkers.
Also, when I brought up postgres for a new project & mentioned it being open source, response was "that means it could vanish any day"
Inertia is real
1. MySQL has a simpler permission model, so user management is less of a headache.
2. Connections are cheaper in MySQL so you don't have to use an external connection pooler like pgbouncer.
3. There's more/better documentation on MySQL performance tuning, especially from Percona.
That's really it for me.
Postgresql is following a blacklist access model which is really hard to get right, a whitelist approach like mysql would be much easier.
I don't think this is quite right. When a new user is created in Postgres, I don't believe any permissions are implicitly GRANTed by default aside from CONNECT. And I believe the only default privileges granted on a given database are to its owner. Is it possible your experience has only been with configurations in which your PG user was either the owner of the database or a superuser?
EDIT: clarification
[1] https://aws.amazon.com/de/blogs/database/managing-postgresql...
In particular, note the justification for the default:
> Keep the default. All users access the public schema implicitly. This simulates the situation where schemas are not available at all, giving a smooth transition from the non-schema-aware world. However, this is never a secure pattern. It is acceptable only when the database has a single user or a few mutually-trusting users.
Note that you can change the set of default privileges, including the grant to PUBLIC. E.g. ALTER DEFAULT PRIVILEGES REVOKE ALL ON TABLES FROM PUBLIC;
> The only way to remove this is to remove the rights on the public role affecting every other user. In this case the mysql concept is better as every new user has by default absolutely no rights.
This seems a bit contradictory...
Or you just use the text protocol and escape your parameters in the app...
This is a very good and fair question. Postgres is growing a lot, but is it growing enough, according to its true potential? It has everything: incredibly robust and trusted; very large feature set; not under any company's direction; extremely liberal license. Should be conquering the database market, and by far is not!
I don't have an answer. I have potentially, many. Possibly I will blog about this at some time. But I believe that definitely it should be growing more and becoming more relevant than it is right now.
This is no detriment at all to all the fantastic work done by everybody; but just the ambition that Postgres can and should go farther.
Real work gets done with PostgreSQL. You can't buy something from Amazon.com without using PostgreSQL. The more Amazon talks about that in their ecosystem, the more PostgreSQL becomes the default choice for all new developers within that (very large) ecosystem.
When you combine that with the loud presence of another 800lb Gorilla promoting PostgreSQL (MSFT), the market has spoken.
It is almost guaranteed that if a client is running on MySQL, you can be certain their entire code base is going to be plagued with less-than-best-practices. Not to be too harsh, but MySQL's most prominent use case is for projects that start with "let's just stand-up a DB real quick and we'll sort out the hard stuff later".
https://babelfish-for-postgresql.github.io/babelfish-for-pos...
> I don’t have an MBA, but this to me is a clear case of The Innovator’s Dilemma. PostgreSQL protocol v3 is the incumbent, and protocol v4 and/or other protocols like HTTP are the potential disruptive innovators.
I have no idea what Christensen means by "disruptive technology". https://en.wikipedia.org/wiki/Disruptive_innovation
The fifth qualifier "New firm's business model differs significantly from incumbent" seems important.
The rest feel like Just So stories. Especially "Originate in low-end (less demanding customers) or new market (where none existed) footholds".
I think time has shown Peter Drucker to be more right. First target affluent customers and then ride the cost curve down towards market success.
I just reread Innovator's Dilemma, and searched the rest. Nothing about cost curves.
I've been trying to think of how "disruption" would apply to Tesla vehicles and Apple Silicon. Neither products came in as "toys".
Rather, I think both initially targeted very high end niches (novel use cases), and the underlying enabling technology was just starting their cost trajectories, whereas the incumbent mass market products were at the end of their trajectories. Plough metric tons of cash into R&D and wait for the new to overtake the old.
--
Back to AWS Babelfish.
AWS adds TDS and T-SQL compatibility to steal business from Microsoft Azure. Just some more bullet list items for middle management purchase bots to check off.
It'll surely improve, but switchover costs for non-trivial projects would still be pretty high. Back when I was warehousing medical records on both MSSQL and Oracle, all the hard work was tweaking the physical design, eg codesigning the indices and queries, to make stuff performant. I'm sure that's still true.
I think adding these features to Postgres is good for everyone but Microsoft.
--
I guess I object to the common use of "disruption". As though there's an element of surprise.
I'd suggest the OP framed AWS Babelfish in terms of competitive threats (aka insurmountable opportunities). And maybe predict some unforeseen consequences.
On the positive side: The meaning of "disruptive innovation" wonderfully Agile. Perfect for consultants, pundits, and polywogs.