📁 Google Workspace

Google Drive — Logical Data Architecture

Behavioral and logical model of how Google Drive stores files, folders, and permissions. Hover over any component for technical detail.

ⓘ Hover over any item to see detailed technical information

⚠️
Key Distinction: Drive is not a filesystem
Google Drive uses an object store with pointer-based parent relationships, not a hierarchical filesystem. Files are identified by unique IDs, folders are just special file objects, and a file can have multiple parent folders simultaneously — making true folder paths a derived/resolved concept, not a stored one.
🗂️
File Object Model
How individual files are stored
Unique File ID
Immutable primary key, not a path
Unique File ID
Every file in Drive has a unique, immutable ID (e.g. 1BxiMVs0XRA5nFMdKvBdBZjgmUUqptlbs74OgVE2upms). This ID never changes regardless of renames, moves, or parent changes. The Drive API uses this ID in every endpoint.
  • Assigned at creation, never changes
  • Survives renames and moves
  • Shareable links use this ID
  • Bookmarks/shortcuts remain valid after move
File Metadata Record
Name, MIME type, owners, parents
File Metadata Record
Each file object has a metadata record containing: name, mimeType, createdTime, modifiedTime, owners (array), parents (array of folder IDs), permissions, size, and application-specific properties. The content is stored separately from metadata.
  • Metadata and content stored separately
  • Parents is an array — multiple parents allowed
  • Supports custom metadata via appProperties
  • Full metadata in Drive API files.get
Content Store
Binary blob separate from metadata
Content Store
File content is stored in Google's object storage infrastructure (built on Colossus), separate from the metadata database. Google Workspace files (Docs, Sheets, Slides) have no binary blob — they are stored natively and exported on demand.
  • Google-native formats: no blob, stored natively
  • Uploaded files: blob in object store
  • Quota charged only for non-Google formats
  • Retrieved via files.get with alt=media
📂
Folder Model
Folders are not containers — they're nodes
Folders as File Objects
mimeType: application/vnd.google-apps.folder
Folders as File Objects
A folder in Drive is just a file with mimeType: application/vnd.google-apps.folder. It has no actual contents — it only serves as a parent pointer target for other files. Folders have their own file IDs and can be shared, starred, and searched like any file.
  • No "contains" relationship in storage
  • Children point to parent, not vice versa
  • Folders can be parents of other folders
  • Deleting a folder orphans children (with warning)
Parent Pointer Model
Files declare their parents
Parent Pointer Model
In Drive, a file declares its parents (array of folder IDs). The folder does not maintain a list of children — the relationship is stored on the file itself. This is the inverse of a filesystem, which stores children in directory nodes.
  • files.list with q="'folderID' in parents"
  • Folder "size" is computed, not stored
  • Moving = updating parent array
  • No path string stored anywhere
Multi-Parent Files
One file, multiple folder parents
Multi-Parent Files
A file in Drive can be "in" multiple folders simultaneously — each folder ID appears in the file's parents array. This is impossible in a true filesystem. The file isn't copied; there's one object with multiple parent references.
  • Enabled via Drive API addParents parameter
  • Not exposed in Drive UI (one location shown)
  • Migration tools must handle this explicitly
  • Deleting one parent doesn't delete the file
🔐
Permissions Model
Object-level ACL, not path-based
Per-Object ACLs
Each file has its own permission list
Per-Object ACLs
Permissions in Drive are stored per file object as an Access Control List (ACL). Each permission entry specifies: role (owner/organizer/fileOrganizer/writer/commenter/reader), type (user/group/domain/anyone), and the grantee identity.
  • Independent of folder permissions
  • Up to 100 ACL entries per file
  • Owner can transfer, writers cannot
  • Permissions API: permissions.list
Inherited Permissions
Folder sharing propagates to children
Inherited Permissions
When a folder is shared, Drive propagates permissions down to child files. However, this is a behavioral layer, not a storage constraint — files maintain their own ACLs. "Inherited" permissions appear as separate entries with an permissionDetails.inherited: true flag.
  • Inheritance is computed at read time
  • Not stored as inherited — stored as separate entries
  • Child can have additional direct permissions
  • Removing folder share removes inherited entries
Shared Drives vs My Drive
Ownership model differs
Shared Drives vs My Drive
In Shared Drives (formerly Team Drives), files are owned by the organization, not an individual. The owner field is the Shared Drive itself. Permissions are managed at the Shared Drive membership level with roles (manager/content manager/contributor/commenter/viewer).
  • No individual file ownership in Shared Drives
  • Org retains files if member leaves
  • 5 role levels vs 6 in My Drive
  • Must be enabled per org policy
🔄
Versioning & Revisions
How file history is stored
Revision History
Immutable snapshot per save
Revision History
Drive keeps a revision history for uploaded files (not Google-native formats, which use change history). Each revision is a separate object with its own ID, size, and creation timestamp. Revisions are accessible via the revisions.list API.
  • Revisions stored as separate objects
  • Older revisions auto-purged after 30 days or 100 revisions
  • Can pin revisions to keep them permanently
  • Google Docs: use Drive Activity API for change history
Trash & Recovery
Soft-delete with 30-day expiry
Trash & Recovery
Deleting a file sets a trashed: true flag and trashedTime on the file object. The file remains in the store and retains its file ID. After 30 days (or manual empty), the file is permanently deleted from the store.
  • trashed = metadata flag, not moved
  • File ID preserved during trash period
  • Admins can restore via Google Workspace Admin
  • Vault holds override 30-day auto-delete
🔗
Shortcuts & References
Cross-drive and cross-domain linking
Drive Shortcuts
Pointer objects, not copies
Drive Shortcuts
Shortcuts are special file objects (mimeType: application/vnd.google-apps.shortcut) that contain a reference to another file's ID and a target MIME type. They behave like symbolic links — deleting the target breaks the shortcut, not vice versa.
  • Does not duplicate storage
  • Can point across Shared Drives
  • Replaced multi-parent files in the UI
  • shortcutDetails.targetId references the target
External Links
Third-party content integration
External Links
Drive supports linked objects from third-party providers (e.g., Salesforce, DocuSign) that appear as Drive files but content is stored externally. These use the Drive Connected Sheets or Drive Third-party app integration protocols.
  • Metadata in Drive, content external
  • Requires app-specific authentication
  • Not migrated by standard Drive migration tools
  • Appear as regular files in search results
🔍
Search & Indexing
Content and metadata discovery
Full-Text Content Index
Document and attachment content indexed
Full-Text Content Index
Drive indexes the text content of Google Docs, Sheets, Slides, PDFs, and many uploaded document formats. Search results are ranked by relevance and recency. The index is updated near-real-time for Workspace-native formats.
  • Google-native formats indexed immediately
  • Uploaded files indexed within minutes
  • Binary formats require conversion step
  • Supports fullText query in files.list API
Drive Search Operators
Metadata predicate queries
Drive Search Query Syntax
The Drive API files.list endpoint accepts a query string with operators: name contains 'text', mimeType = '...', 'folderID' in parents, fullText contains 'text', modifiedTime > '2024-01-01'. Queries are evaluated against the metadata and search index.
  • Operates on object store, not filesystem paths
  • No path-based queries available
  • parents operator resolves to a single level
  • Must recurse manually for deep folder search
Behavioral Comparison: Traditional Filesystem vs Google Drive

Traditional Filesystem

  • Files identified by path (e.g., /projects/2024/doc.docx)
  • Folders are containers with lists of children
  • A file can only exist in one folder
  • Moving = changing the path
  • Renaming changes the file's identity/path
  • Permissions often inherited via path structure

Google Drive Object Store

  • Files identified by unique ID (immutable)
  • Folders are just nodes in the object graph
  • A file can have multiple parent folders
  • Moving = updating the parents array
  • Renaming does not change the file ID
  • Permissions are per-object ACLs (computed inheritance)
File Upload Flow
Client Upload
HTTP multipart or resumable
→
Content Scan
Malware + DLP check
→
Object Store
Blob written, quota updated
→
Metadata Record
File ID assigned, parents set
→
Index Update
Content indexed for search
→
ACL Propagation
Parent permissions inherited
Legend
File object model
Folder / parent model
Permissions / ACL layer
Versioning and trash
Shortcuts and links
Search and indexing

Architecture Documentation Notes

Key Insight: No Real Paths

Drive has no concept of a stored file path. When you see /My Drive/Projects/2024/doc.docx in the UI, that path is resolved at display time by traversing parent pointers. The same file can show up at multiple display paths if it has multiple parents.

Migration Implication

Migration tools (ShareGate, Quest, Google Workspace Migration) must enumerate Drive by traversing the parent graph, not by reading a directory tree. Files with multiple parents need explicit handling to avoid duplicates. Permissions must be re-evaluated post-migration as ACLs are object-level.

API Access Model

The Drive API v3 is entirely file-ID centric. List operations require a query string; there is no "ls" equivalent. To enumerate a folder, query files.list with 'folderID' in parents. Recursive enumeration requires iterating each subfolder in a loop or using corpora parameter with Shared Drive scope.

Source Confidence

File ID model, parent pointer model, folder as mimeType, shortcut model: all documented in Google Drive API v3 official documentation. Underlying storage infrastructure (Colossus, Bigtable): described at architectural level in Google Research papers; implementation details not publicly disclosed.