This depends on the architecture of your application, but judging from the examples provided I assume you are referring to web-services served through user agents such as browsers or native apps. The issue with server-managed sessions is that they go against the idea of statelessness.
"Google, Facebook, and others" usually handle sessions through persistent cookies which possess information to re-authenticate against an identity provider serving as the respective organization's own authorization server. The identity provider then again issues access tokens on behalf of the user to gain access to a resource (see OAuth and OIDC). This way the server is generally agnostic towards the concept of sessions.
I can't give you any precise numbers, but smaller companies not rarely rely on certain charged providers to set up an identity provider on their behalf. Since this is a non-trivial task companies who lack the resources not rarely rely on persistent cookies to authenticate directly against the resource server. Virtually any major framework possesses the tools to build such an architecture.
Do not let your security rely purely on a high-entropy session id.
Keep in mind that the user agent possesses a lot of attack surface to nick all sorts of stored information. Encrypted HttpOnly-cookies served only over HTTPS should be the bare minimum.