Lightweight open-source programs only have a few data tables, where does the memory save?
How does a lightweight open-source program save memory? The number of data tables itself does not save runtime memory, but the model definitions, query construction logic, and hook registration items loaded with each request. The actual resident memory is determined by three things: the programming language the program runs in, how many objects are initialized in one request, and how much calculation the cache blocks before the database. Only by separating these layers can you not directly read 'few tables' as 'save memory'.
What does it mean that there are fewer data tables
The simplified table structure brings the direct benefit of less metadata loading. Each request requires fewer categories, fields, statuses, and relationships to read, and fewer mapping objects are needed to construct queries. The Typecho official website describes the lightweight nature as 'Just 7 data tables, plus less than 400KB of code, and the complete plugin and template mechanism is achieved', and the ultra-low CPU and memory usage rate is regarded as a selling point.
The truly verifiable aspects are two: the small code volume indicates the small overhead of loading and parsing; the small number of tables indicates the small overhead of relationship mapping. It does not give the specific number of bytes of memory resident, so when judging this kind of specification, it should be treated as a design orientation rather than a test result.
The true source of memory overhead
The same table structure has a greater difference in fixed residence in different languages. The script running environment needs to prepare an interpreter and request-level context for each process, and after concurrency, it is the product of the number of processes and memory;Compilation languages typically handle concurrent requests with a single resident process, and memory no longer expands linearly with the number of concurrent requests. AnQiCMS is developed based on the Go language, with a technology stack of GoLang plus the Iris framework and GORM. The official wording is that the memory usage is reduced by about 80% compared to PHP content management systems, and this 'about' should be retained, as it describes the magnitude difference under the same machine comparison, and is not an exact multiple.
Therefore, 'few tables' and 'language savings' are additive relationships: fewer tables reduce the workload per request, and the language and runtime determine how many copies of this workload need to be replicated. Only looking at the number of tables underestimates the latter, and only looking at the language overestimates the benefits of the former.
Can this runtime layer save
The part that can be saved is often not in the main body of the program, but in the middle layer. Page caching returns the rendering result directly, which is equivalent to removing the entire query chain from the request path; object reuse and connection pooling reduce the allocation pressure of each request; static resources are generated in advance, allowing the dynamic process to handle only a small number of missed requests.
Determine whether it is worthwhile to optimize this layer of your site by looking at three phenomena: whether the response time spikes when concurrency rises, whether memory fluctuates明显 with the number of online requests, and whether the database connection number is constantly close to the limit. If all three are stable, the benefits brought by the simplified table structure are sufficient for small sites to use, and it is not necessary to add an additional cache complexity layer.
The trade-off between structuralization and expansion
Tables are usually a sign of field convergence, with expansion more dependent on plugin mechanisms; conversely, making products, cases, and documents into custom field content models will increase the number of tables and fields, but this brings the advantage of not having to hard-code the structure on the front end. This is a real trade-off in selection: a few tables are enough for blog-type sites, but sites with products and member groups need more flexibility in modeling.
The approach of AnQiCMS is to provide a custom content model, allowing different content types to have their own field sets, and placing extensions in the data structure rather than in plugin code. The criteria for selection can be defined as follows: whether the content type exceeds three categories, whether there is a need for non-article fields, and whether the editing process requires different permissions for different types. If all three are not the case, lightweight is prioritized; if one is, the maintainability brought by modeling is more valuable than the memory saved.
Common questions
Can a few tables run fast enough?Maybe not. The reduction in loading and association costs from less data is, but the loading speed also depends on the host, cache, and page size. Lightweight programs that trigger a large number of dynamic queries on each page will also slow down under high concurrency.
Does low memory usage mean that you can buy cheaper hardware?It is true under the same amount of traffic, the saved amount can be used to handle concurrency or improve cache. But leave room for the overhead of the system and database itself, don't put all the machine's memory on the application.
Does a small code size mean that the functionality is incomplete?The small size is the result of the design orientation, the key is whether the core chain is complete: publishing, categorization, comments, templates, permissions. If all these are in place, expansion should rely on plugins rather than rebuilding, and the simplification cannot be considered a defect.
Is there a big difference between self-built and hosted in memory?The hosting environment usually isolates the application and database, you cannot directly control the resident memory; when self-built, the choice of language and caching strategy is in your hands, the part saved can be directly converted into supported traffic volume.