It is possible to design scale-out database engines with very fast and elastic load following though it isn't common. In these kinds of systems, you don't provision for load, the system automatically adjusts to the load as it happens. In good designs you can often shed load in milliseconds once the additional server capacity is online, so the latency is often a function of how quickly you can bootstrap more server images.

These kinds of fast-twitch load shedding mechanics were not designed for elasticity -- it would not be worth the engineering investment in most cases. They were typically developed to support scale-out of data models for which uniform sharding is intrinsically impossible, requiring real-time adaptive resharding instead. If you have super-fast load shedding for extremely and unpredictably biased data distributions, you are 90% of the way to a really nice implementation of elastic capacity, just add hardware provisioning.

These setups are nice as a user, because the sharded nature of a table is (necessarily) completely transparent. You can create an empty new table and insert trillions of records without every having to manage sharding or cluster capacity as the table grows. In this sense, the fact that it is running on a cluster of discrete servers does not leak through the database abstraction presented to the user.