3 ms·

I recently took a part time role at Oracle Labs and have been learning PL/SQL as part of a project. Seeing as Niki is shilling for his employer, perhaps it's OK

I recently took a part time role at Oracle Labs and have been learning PL/SQL as part of a project. Seeing as Niki is shilling for his employer, perhaps it's OK for me to do the same here :) [1]. HN discourse could use a bit of a shakeup when it comes to databases anyway. This may be of only casual interest to most readers, but some HN readers work at places with Oracle licenses and others might be surprised to discover it can be cheaper than an AWS managed Postgres [2]. It has a couple of features relevant to this blog post. The first: Niki points out that in standard SQL producing JSON documents from relational tables is awkward and the syntax is terrible. This is true, so there's a better syntax: CREATE JSON RELATIONAL DUALITY VIEW dept_w_employees_dv AS SELECT JSON {'_id' : d.deptno, 'departmentName' : d.dname, 'location' : d.loc, 'employees' : [ SELECT JSON {'employeeNumber' :e.empno, 'name' : e.ename} FROM employee e WHERE e.deptno = d.deptno ] } FROM department d WITH UPDATE INSERT DELETE; It makes compound JSON documents from data stored relationally. This has three advantages: (1) JSON documents get materialized on demand by the database instead of requiring frontend code to do it, (2) the ORDS proxy server can serve these over HTTP via generic authenticated endpoints (e.g. using OAuth or cookie based auth) so you may not need to write any code beyond SQL to get data to the browser, and (3) the JSON documents produced can be written to, not only read. The second feature is query change notifications. You can issue a command on a connection that starts recording the queries issued on it and then get a callback or a message posted to an MQ when the results change (without polling). The message contains some info about what changed. So by wiring this up to a web socket, which is quite easy, the work of an hour or two in most web frameworks, then you can stream changes to the client directly from the database without needing much logic or third party integrations. You either use the notification to trigger a full requery and send the entire result json back to the browser, or you can get fancier and transform the deltas to json subsets. It'd be neat if there was a way to join these two features together out of the box, but AFAIK if you want full streaming of document deltas to the browser and reconstituting them there, it would need a bit more on top. Again, you may feel this is irrelevant because doesn't every self-respecting HN reader use Postgres for everything, but it's worth knowing what's out there. Especially as the moment you decide to paying a cloud for hosting your DB you have crossed the Rubicon anyway (all the hosted DBs are proprietary forks of Postgres), so you might as well price out alternatives. [1] and you know the drill, views are my own and nobody has reviewed this post. [2] https://news.ycombinator.com/item?id=42855546 https://news.ycombinator.com/item?id=42855546

vessenes 2y ago
Lots of good people work at Oracle, and I am sure you're one of them. HOWEVER. There is no world where lifetime costs of using Postgres for any successful company anywhere in the world are greater than using Postgres. I understand that's a key message for your sales team to get out, but only one of the CEOs at Oracle and Percona has flown a fighter jet underneath the Golden Gate Bridge. Oracle licensing is famously, famously sticky. Extremely. Incredibly. It's how the company was built and is maintained.
- mike_hearn 2y ago
  Great, let's debate! I've never talked to database sales people and have no idea what messages they have or care about. Actually I'm 99% sure they don't care about the HN/startup crowd at all - did you see anyone except me talk about this stuff here? Me neither. I'm making this argument basically because I like making arguments early that are surprising but correct, and databases feel like fertile ground for such arguments. There's a lot of groupthink in this space. And you know all about my history with surprising technology arguments, Peter ;) Anyway I'd be interested to see a spreadsheet with a worked set of scenarios for both cost and "stickiness" however it's defined (genuinely). I think it's going to depend heavily on: a) Whether you cloud host or not. The cost of a small Postgres that you run yourself is pretty much whatever your own time is valued at, as self-hosted hardware is cheap. The costs of a Postgres you outsource can be really un-intuitively high. I already showed that a cloud hosted elastic Oracle DB can be cheaper for the same-spec AWS-managed Postgres despite a massive feature disparity on one side. Costs here aren't dominated by hardware nor software purchase costs. b) What features and scaling level you need, combined with cost of labour in your area. If you want to scale up a Postgres based operation very fast then that's going to take a ton of skilled engineering effort, devs will be slowed down a lot as they spend time on implementing custom sharding schemes etc. At some point the cost of rolling your own ad-hoc solutions to these things will cross with the cost of just buying a system that already solves them all out of the box. Where that cross-point is will depend on all kinds of things like opportunity cost, cost of hiring, cost of developer productivity.... b) Whether you consider unique features to be "stickiness". You're claiming the licensing is sticky here but companies negotiate all kinds of licenses so what does that mean? By default it's charged per core like any other commercial db (or in the cloud by core seconds/storage). If unique features are the problem then that's an aspect of choosing any tech platform. If you're taking advantage of full SQL joins on a 50-node horizontally scaled multi-master cluster then yeah, trying to migrate to something else is going to be sticky because there aren't many other products that offer that. That's tech for you. Still, these days I guess it must be less sticky because there are other people selling very scalable SQL-speaking databases like Spanner. As for Larry Ellison's stunts, that's great but if you're deciding what platform to use on the basis of executive horsepower then you can pick between fighter jets, Jeff Bezo's rockets, Bill Gates' yachts or Larry Page's flying cars. Selling databases seems to go hand in hand with high tech vehicles, which is probably a sign there's some actual value being delivered there, somewhere.

vessenes 2y ago

Lots of good people work at Oracle, and I am sure you're one of them. HOWEVER. There is no world where lifetime costs of using Postgres for any successful company anywhere in the world are greater than using Postgres. I understand that's a key message for your sales team to get out, but only one of the CEOs at Oracle and Percona has flown a fighter jet underneath the Golden Gate Bridge. Oracle licensing is famously, famously sticky. Extremely. Incredibly. It's how the company was built and is maintained.

mike_hearn 2y ago
Great, let's debate! I've never talked to database sales people and have no idea what messages they have or care about. Actually I'm 99% sure they don't care about the HN/startup crowd at all - did you see anyone except me talk about this stuff here? Me neither. I'm making this argument basically because I like making arguments early that are surprising but correct, and databases feel like fertile ground for such arguments. There's a lot of groupthink in this space. And you know all about my history with surprising technology arguments, Peter ;) Anyway I'd be interested to see a spreadsheet with a worked set of scenarios for both cost and "stickiness" however it's defined (genuinely). I think it's going to depend heavily on: a) Whether you cloud host or not. The cost of a small Postgres that you run yourself is pretty much whatever your own time is valued at, as self-hosted hardware is cheap. The costs of a Postgres you outsource can be really un-intuitively high. I already showed that a cloud hosted elastic Oracle DB can be cheaper for the same-spec AWS-managed Postgres despite a massive feature disparity on one side. Costs here aren't dominated by hardware nor software purchase costs. b) What features and scaling level you need, combined with cost of labour in your area. If you want to scale up a Postgres based operation very fast then that's going to take a ton of skilled engineering effort, devs will be slowed down a lot as they spend time on implementing custom sharding schemes etc. At some point the cost of rolling your own ad-hoc solutions to these things will cross with the cost of just buying a system that already solves them all out of the box. Where that cross-point is will depend on all kinds of things like opportunity cost, cost of hiring, cost of developer productivity.... b) Whether you consider unique features to be "stickiness". You're claiming the licensing is sticky here but companies negotiate all kinds of licenses so what does that mean? By default it's charged per core like any other commercial db (or in the cloud by core seconds/storage). If unique features are the problem then that's an aspect of choosing any tech platform. If you're taking advantage of full SQL joins on a 50-node horizontally scaled multi-master cluster then yeah, trying to migrate to something else is going to be sticky because there aren't many other products that offer that. That's tech for you. Still, these days I guess it must be less sticky because there are other people selling very scalable SQL-speaking databases like Spanner. As for Larry Ellison's stunts, that's great but if you're deciding what platform to use on the basis of executive horsepower then you can pick between fighter jets, Jeff Bezo's rockets, Bill Gates' yachts or Larry Page's flying cars. Selling databases seems to go hand in hand with high tech vehicles, which is probably a sign there's some actual value being delivered there, somewhere.