Structure vs. value
Every property on a document type has two separate things going on: a definition (which data type it uses, its alias, which tab or group it sits in) and a value (whatever an editor actually typed or selected). The structural definition lives in Umbraco's own database tables. The value lives separately, tied to a specific content item and a specific version of that content item.
The database layer
Umbraco is backed by a relational database, SQL Server by default, and property values are stored in tables tied to content versions. Every time a content item is saved, Umbraco can create a new version, which is part of how rollback and version history work. Exact table names have changed across major Umbraco versions, the legacy Umbraco 7 schema differs from the schema used in Umbraco 8 and later, so I'm deliberately not quoting specific table names here as if they were stable across every version. If you need that level of detail, the safest source of truth is your own database or the version-specific Umbraco source, not a blog post that'll be out of date by the next major release.
Worth knowing separately: many property editors, rich text, block list, and other nested-content-style editors, store their value as a single block of serialised JSON in one database field, rather than as separate relational rows. That's why a property that looks simple in the backoffice can actually be a fairly complex nested structure underneath.
The published cache (NuCache)
Reading straight from SQL on every single page request would be slow, so Umbraco maintains an in-memory published-content cache, NuCache, backed by a local file (typically a SQLite database cached to disk) so a restart doesn't require rebuilding the entire cache from scratch. Front-end requests for published content are served from this cache, not from a live SQL query. That's also why a database edit made by bypassing Umbraco directly won't show up on the site until the cache is told to rebuild.
The search index (Examine)
Separately again, Umbraco maintains Lucene-based search indexes through Examine, which store their own searchable, sometimes flattened, copy of property values purely for querying. That's a third representation of the same underlying data, optimised for search rather than storage or rendering.
Why this matters practically
Three things fall directly out of this: a database-level edit that bypasses Umbraco won't show up on the live site without a cache rebuild; Examine search results can lag slightly behind a save if the index hasn't caught up; and exporting or migrating "content" between environments is a bigger job than just copying database rows, since the published cache and search index both need to reflect whatever ends up in the database.
If you're debugging something specific
If data isn't showing up where you expect and this is the reason, it's usually a support or performance issue rather than a training one. See services for how that kind of work gets scoped.