One interesting thing about Barman is that it just uses PG's own backup utilities. It doesn't implement custom parsers and things like that. So, there's less maintenance work needed for Barman when PostgreSQL changes data-file internals. Tradeoff is that there's less custom optimization than pgBackRest/pg_probackup/WAL-G-local.
Databasus seems to be taking somewhat similar approach to Barman, but (at this time) does not appear to use pg_receivewal, which makes it less efficient than Barman.
For PG v17+, Barman seems to be the most efficient backup solution based on PG native tools, that is able to do low-RPO or even zero-RPO (if configured as a synchronous receiver).
**Backup types**
- **Logical** — Native dump of the database in its engine-specific binary format. Compressed and streamed directly to storage with no intermediate files
- **Physical** — File-level copy of the entire database cluster. Faster backup and restore for large datasets compared to logical dumps
- **Incremental** — Physical base backup combined with continuous WAL segment archiving. **Enables Point-in-time recovery (PITR)** — restore to any second between backups. Designed for disaster recovery and near-zero data loss requirements
EDIT: It seem PITR has been added this March (for PostgreSQL)
Handling of exceptions is not enforced at compile time, while ownership is.
Better example might be statically typed languages. They were harder to use at first, but now with good type inference and features like generics, they are much more ergonomic than at first. The accessibility gap between static and dynamic languages has narrowed with time and maybe we can expect that user-friendliness of ownership will also improve like that.
That's due to trimming which can be also be enabled for self-contained builds that use JIT compilation. Trimming is mandatory for AOT though. But you can use annotations to prevent trimming of specific thing.
AOT doesn't support generating new executable code at runtime (Reflection.Emit), like you can do in JIT mode.
From what I've read, this is for the first implementation of unions, to reduce amount of compiler work they need to do. They have designed them in a way they can implement enhancements like this in the future. Things like non-boxing unions and tagged unions / enhanced enums are still being considered, just not for this version.
This is the general pattern of how the C# team operates, IME.
"Never let perfect be the enemy of good"
Very much what I've seen from them over the years as they iterate and improve features and propagate it through the platform. AOT as an example; they ship the feature first and then incrementally move first party packages over to support it. Runtime `async` is another example.
In the meantime I still haven't done any project with nullable references, because the ecosystem has yet to move along. Same applies to ValueTask for async code.
Which part of the ecosystem is blocking your projects from using nullable references? I find them very helpful, but the projects were all newer or migrated to new SDK.
It is relatively easy to find corporate libraries, or commercial products that still aren't using it, including Microsoft products still stuck in .NET Framework, or .NET standard 2.0.
If you want name shaming of commercial products with modern .NET, here is one, can provide more.
You can use dependencies that aren't using nullable reference types in projects that use it. You can enable/disable nullable reference types per file, as it only influences static analysis. There's no runtime difference between a non-nullable reference type and a nullable reference type.
Databasus seems to be taking somewhat similar approach to Barman, but (at this time) does not appear to use pg_receivewal, which makes it less efficient than Barman.
For PG v17+, Barman seems to be the most efficient backup solution based on PG native tools, that is able to do low-RPO or even zero-RPO (if configured as a synchronous receiver).
reply