- Updatable views (also over multiple tables)
- Array and JSON fields
- Point-in-time backup and recovery (WAL files archiving)
I find, sometimes, that it is too restrictive in cross-table/view constraints. This is very annoying as I needed to change a field definition from VARCHAR(10) to VARCHAR(30) and, having a group of views depend in it, the only solution was to implement a function that would:
It took me like three or four hours (and caused a lot of stress) to make such a simple change. To me it looks a bit too overkill, especially nowadays that application requirements and implementation change so often.
I have used it for one and a half years.
There were no problems with deployment.
The app hasn’t had the need to scale much yet.
It was quite straightforward.
I implemented it myself and don’t have any particular advice about it. Today I would consider implementing it via Docker.
I've only used online open source resources and would say there's not as much as there is for MySQL. Sometimes it took me some time to find a good solution to the more unusual scenarios