Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Oracle vs. PostgreSQL: First Glance

rolkotech.blogspot.com

Post reply on HN
Print view View original

141–150 of 201 posts

Re: Oracle vs. PostgreSQL: First Glance

#141

Post by cryptonector »

F_J_H wrote: post #24
markab21 wrote: post #14

Why anyone would use Oracle for anything other than supporting legacy systems is beyond me.

I have not been an Oracle fan in the past, especially because of their complicated (and expensive) licensing, but late last year we moved to their hosted autonomous database. The on demand pricing model makes it quite economical, and the performance is amazing. However, the killer feature for me is that it has application Express (or APEX) included, which is a complete web application development framework, as well a…

PostgreSQL + PostgREST == blinding light.

You get a RESTful interface to PG. All you need to add is a static page w/ some JS, for which you can use react-admin or similar.

Presto: web apps written in PG.

Re: Oracle vs. PostgreSQL: First Glance

#142

Post by ants_a »

takeda wrote: post #114
munk-a wrote: post #80

Earlier quoted context omitted.

Coming from MySQL to Postgres a few years back the transactional DDL statements were a joy to work with - I've had to claw a legacy into the modern era and utilizing them has allowed me to execute live migrations from legacy into shims and then from shims into modern. I also really appreciate the transactional TRUNCATE - I pretty much never use it but at least in Postgres I never have to worry about someone else tryi…

> I also really appreciate the transactional TRUNCATE - I pretty much never use it but at least in Postgres I never have to worry about someone else trying to run one and wiping state unexpectedly. as long as auto commit is not enabled. These goodies are possible, because of PostgreSQL's MVCC which requires running vacuum. Nothing is for free unfortunately.

I don't think undo vs. heap based MVCC choice has any big impact with regards to transactional truncate, nor transactional DDL in general. You are likely to see proof of that within a couple of years.

Re: Oracle vs. PostgreSQL: First Glance

#143

Post by jsmith45 »

takeda wrote: post #114
munk-a wrote: post #80

Earlier quoted context omitted.

Coming from MySQL to Postgres a few years back the transactional DDL statements were a joy to work with - I've had to claw a legacy into the modern era and utilizing them has allowed me to execute live migrations from legacy into shims and then from shims into modern. I also really appreciate the transactional TRUNCATE - I pretty much never use it but at least in Postgres I never have to worry about someone else tryi…

> I also really appreciate the transactional TRUNCATE - I pretty much never use it but at least in Postgres I never have to worry about someone else trying to run one and wiping state unexpectedly. as long as auto commit is not enabled. These goodies are possible, because of PostgreSQL's MVCC which requires running vacuum. Nothing is for free unfortunately.

Interestingly even though MSSQL server uses an extremely different implementation of MVCC, it internally has a vacuum equivalent. (Which is required even when all MVCC support is disabled! It is used to enable efficient implementation of deletes, without having to use absurdly coarse locks).

MSSQL just handles doing that cleanup silently in the background while exposing basically no no configuration except a trace flag that can turn it off.

Re: Oracle vs. PostgreSQL: First Glance

#144

Post by ants_a »

F_J_H wrote: post #54
jedieaston wrote: post #45

Earlier quoted context omitted.

>application express Is it smart to have all of your web app code running in the database, making it impossible to run without the Oracle Database?

That is somewhat of a concern, but less so now that they support web services. So, you would still need a basic oracle DB set up in order to run APEX, but you could just use OracleXE, which is a quite capable free version, and then connect to whatever you want. Also, you see this argument a lot - "what if I want to switch databases"? I've seen more than my share of overly-complicated and highly non-performant code ba…

"What if I want to switch" is a valid question if your business is at the mercy of a single vendor with a history of abusive business practices towards its customers.

While I may have a selection bias, I have seen quite a lot of companies migrating their applications, successfully. Most for exactly this reason. And many, perhaps even more, that would very much like to migrate if it was less disruptive.

Re: Oracle vs. PostgreSQL: First Glance

#145

Post by F_J_H »

kstrauser wrote: post #103
F_J_H wrote: post #24

Earlier quoted context omitted.

I have not been an Oracle fan in the past, especially because of their complicated (and expensive) licensing, but late last year we moved to their hosted autonomous database. The on demand pricing model makes it quite economical, and the performance is amazing. However, the killer feature for me is that it has application Express (or APEX) included, which is a complete web application development framework, as well a…

> YRMV, but it has been incredible for us, both to support our data science initiatives, and for rapidly deploying applications. I couldn't imagine going back to anything else. Out of curiosity, are your data scientists actually happy with this? All of ours are using Python notebooks with Spark or RDS, and I think there'd be an armed revolt if we asked them to migrate to anything else.

So far, yes. APEX in this case is used for data visualization and dashboards, mostly using Plotly.js.

And, the oracle database is the data store for clean/structured data. They use python notebooks and all the other python based goodies for their work - the DB is just where they get their data. (And, sometimes it makes sense to do data processing with the DB). We could end up using Spark at some point - we're not precluded from that.

Re: Oracle vs. PostgreSQL: First Glance

#146

Post by catblast »

ntsplnkv2 wrote: post #109
catblast wrote: post #94

Earlier quoted context omitted.

> oracle database is dying an its niche is shrinking. This is true, but misleadingly not the whole truth. On prem RDBMS is dying and its niche shrinking (at least in this part of the cycle)... having said that, Oracle cloud offerings are doing very well. Amazon made a herculean effort, and made some headlines when they migrated most of the business off Oracle last year. That's wonderful, for Amazon. Most of Oracle's…

I mean, a company with as much data as Amazon leaving is a pretty big deal and obviously is in the news. Are Oracle cloud offerings actually doing well? What evidence is there of this?

They’re a publicly traded company, this is readily available information. Sure the growth is not a hockey stick, but they’re not exactly dying either. The way people talk on here you’d think they’re filing for bankruptcy tomorrow.

Re: Oracle vs. PostgreSQL: First Glance

#147

Post by takacsroland »

jcadam wrote: post #2

I've been on a project where we were forced to migrate the opposite direction: From PostgreSQL to Oracle, because the client was already paying for Oracle licenses and really, really , wanted us to use Oracle to justify the expense. It was actually a pretty big setback. We were using PostGIS to support spatial queries (a key requirement), and Oracle Spatial was just not at the same level (both in performance and feat…

Thanks, based on everyone's comment it seems it is a great decision to migrate to Postgre. Cool!

Re: Oracle vs. PostgreSQL: First Glance

#148

Post by takacsroland »

forinti wrote: post #15
jcadam wrote: post #2

I've been on a project where we were forced to migrate the opposite direction: From PostgreSQL to Oracle, because the client was already paying for Oracle licenses and really, really , wanted us to use Oracle to justify the expense. It was actually a pretty big setback. We were using PostGIS to support spatial queries (a key requirement), and Oracle Spatial was just not at the same level (both in performance and feat…

You could connect Oracle to Postgresql using HA and from Postgresql to Oracle using FDW. If your client was paying Oracle already, he should take steps to move away from it, not setup himself up for paying licences forever. I cringe at having to call Oracle Support. It takes forever and they make you send a ton of files before someone even looks at it.

Yes forinti, it is true, I agree.

Re: Oracle vs. PostgreSQL: First Glance

#149

Post by edmundsauto »

cryptonector wrote: post #141
F_J_H wrote: post #24

Earlier quoted context omitted.

I have not been an Oracle fan in the past, especially because of their complicated (and expensive) licensing, but late last year we moved to their hosted autonomous database. The on demand pricing model makes it quite economical, and the performance is amazing. However, the killer feature for me is that it has application Express (or APEX) included, which is a complete web application development framework, as well a…

PostgreSQL + PostgREST == blinding light. You get a RESTful interface to PG. All you need to add is a static page w/ some JS, for which you can use react-admin or similar. Presto: web apps written in PG.

Can you point me to a good resource on this? I work 100% in the data layer right now, but the idea of being able to create an easy frontend (assuming I learn react) would be wonderful.

Re: Oracle vs. PostgreSQL: First Glance

#150

Post by F_J_H »

ants_a wrote: post #144
F_J_H wrote: post #54

Earlier quoted context omitted.

That is somewhat of a concern, but less so now that they support web services. So, you would still need a basic oracle DB set up in order to run APEX, but you could just use OracleXE, which is a quite capable free version, and then connect to whatever you want. Also, you see this argument a lot - "what if I want to switch databases"? I've seen more than my share of overly-complicated and highly non-performant code ba…

"What if I want to switch" is a valid question if your business is at the mercy of a single vendor with a history of abusive business practices towards its customers. While I may have a selection bias, I have seen quite a lot of companies migrating their applications, successfully. Most for exactly this reason. And many, perhaps even more, that would very much like to migrate if it was less disruptive.

Yep - agreed. It's "pick your poison". No matter what tech stack you select, migration away from it is a may be a consideration. (Whether it is a JavaScript framework, PHP to python, C++ to Go, or one DB engine to another.)

If being able to easily switch technology stacks is important to your business success, then you need to optimize for that. That's not the case for me.

Post reply on HN