Memory-Only Tables

Memory-only tables are not persisted by default like a regular table. You can add, modify, or delete records in a memory-only table. A memory-only table name must adhere to the standard naming criteria. Each memory-only table exists within a schema and follows the standard name resolution rules for persisted tables. The following scenarios/endpoints will create a memory-only table (unless persistence is specified):

• Using the /aggregate/groupby, /aggregate/unique, or /aggregate/unpivot endpoints with the result_table option specified
• Projection — created from /create/projection
• Union (also includes intersect and except operations) — created from /create/union
• Creating a table using /create/table with the is_result_table option set to true

​

Considerations

• Ingestion speed is better than persisted tables, as there are no disk writes.
• There’s no reliance on lookups between connected join data sets or scanning mask on filtered data sets, resulting in faster queries.
• All memory-only tables created by endpoints copy data from their source data sets, thus their memory footprint can be quite large compared to a join view or a filtered view.

​

Limitations and Cautions

• Primary Key fields contained within memory-only tables cannot be updated.
• Object ID cannot be used to update or delete records. This means updating or deleting records in a memory-only table is not possible through the GAdmin Data UI.
• A memory-only table is not persisted, by default, and will not survive a database restart, though each endpoint that creates a memory-only table has an option to persist the table instead.
• Memory-only tables can be evicted to disk cache if RAM is limited, thus incurring disk writes
• Individual memory-only table types have additional limitations and properties that may differ from the preceding limitations. More information can be found in Aggregation, Except, Intersect, Projections, and Union.