Database engines typically operate within a giant block of memory allocated at bootstrap which is used quite differently than a heap. Mutable references to the address space necessarily exist outside the address space, which presents problems for conventional memory safety models. There are also no pointers
per se because almost all memory is directly paged -- objects have no fixed memory address over their lifetime. Most shops use a thin wrapper that implements a pointer-like interface (in the style of std::unique_ptr) that hides the paging and scheduling mechanics. The scheduler design, which is where most of the safety and guarantees that resources can't leak happens, is often verified with a model checker. It is perfectly safe to hold an arbitrary number of concurrent mutable references to an object because safe execution will be resolved dynamically at runtime (which is cheaper than it sounds). There are container libraries designed to work seamlessly in this type of memory model. To a developer writing code against this abstraction, it feels similar to a garbage-collected concurrency-safe language. No locking, no resource management. The abstraction isn't general purpose but it works very well for the kinds of data infrastructure applications where people use C++.
In many of these systems it is standard practice to generate arithmetically limited types pervasively. This is almost transparent in C++17. While it is possible to verify much of this at compile-time in theory, it almost never is because it isn't worth the effort (C++20 may start to change this) and testing at runtime has proven to be nearly as good. People underestimate what is possible with the C++ type infrastructure in this regard.
This type of software design was originally done because it allows for exceptional performance but has become popular for safety reasons. It uniquely allows you to make guarantees about runtime behavior under diverse adversarial workloads that would otherwise be difficult to make.
Bugs in practice tend to occur at the interface with third-party code, which requires dropping out of any internal type system, or in the form of performance anomalies due to unexpected hardware behaviors interacting with the scheduler design. Logic bugs in the core bits tend to be found in testing.