Context Switching

[Joubin Houshyar]

I am new to Postgres (love it!) and just heard a bit of potential 'FUD' regarding our projected plans to make substantial use of Postrgres as a 'Database' and not merely a persistence backend with relational sugar.

I would very much appreciate your informed feedback.

In the projected approach, the intent is to

a) make extensive use of the feature set of the RDBMS and not treat it as a vanilla SQL backend.

b) multiple schemas, with focused functional scope -- one database.

c) /only/ expose functions to the external clients.Projected functions would range from SQL to PL/SQL. So, no SQL on the client side and no direct access to the relations.

d) naturally (/g) use triggers, rules, etc. The intent is to have a solid system of record that does not have various bits of its business logic guts spread across the (db) client tiers.

The business domain itself is fairly dreamland as it is mostly read only; easily subject to partitioning; low contention for concurrent actors. The essential data is geometric types (paths, points, etc.) Write once, content addressing semantics.

A (distributed/federated) meta-layer of sorts that is to manage the processing components and pipelines (with its own related schemas) is also projected. This aspect of the system is workflow and production pipeline process control and management (queues for workers, etc.). Naturally there will be contention for data here; federated approach is to address this.

Now the specifics of the potential FUD was that "modular design" and excessive use of functions that would traverse n layers of mixed languages in (exposed/api) functions would kill the performance.

Note that this system and projected architecture would also naturally fit a NoSQL distributed layer (Riak) and scalable application layer (Java/Go) up-front. And it is not too late for us to revisit our plans! :))

So to repeat, I would very much appreciate informed feedback and guidance on this.

Thank you.