{"id":21231,"date":"2026-09-01T11:49:31","date_gmt":"2026-09-01T09:49:31","guid":{"rendered":"https:\/\/webhosting.de\/mariadb-instant-add-column-ohne-downtime-schemaupdate-datenbank\/"},"modified":"2026-09-01T11:49:31","modified_gmt":"2026-09-01T09:49:31","slug":"mariadb-instant-column-addition-without-downtime-schema-update-database","status":"publish","type":"post","link":"https:\/\/webhosting.de\/en\/mariadb-instant-add-column-ohne-downtime-schemaupdate-datenbank\/","title":{"rendered":"MariaDB Instant ADD COLUMN: Schema Changes Without Downtime for Modern Databases"},"content":{"rendered":"<p>With Instant ADD COLUMN, MariaDB introduces a technology that allows me to add new columns to large InnoDB tables in real time\u2014without significant locks and without downtime. The INSTANT algorithm does not overwrite any data, but simply extends <strong>Metadata<\/strong> and thereby returns new columns with default values.<\/p>\n\n<h2>Key points<\/h2>\n\n<p>The following key points help me quickly assess the capabilities of instant operations and make the right decisions for production systems. I summarize the most important aspects and relate them to typical administrative tasks. Based on the interplay between version, table layout, and DDL strategy, I derive specific steps to take. The list serves as a concise reference for daily <strong>Database<\/strong> Administration. Following this overview, I'll delve deeper into implementation, pitfalls, and practical examples.<\/p>\n\n<ul>\n  <li><strong>Downtime<\/strong> Minimize: Add new columns in milliseconds without a rebuild or copy operations.<\/li>\n  <li><strong>Online DDL<\/strong> To ensure safe operation: Explicitly specify ALGORITHM=INSTANT and LOCK=NONE.<\/li>\n  <li><strong>Version<\/strong> Note: 10.3\u2014only the last column; starting with 10.4, flexible positions and more.<\/li>\n  <li><strong>Metadata<\/strong> Instead of data: No physical overwriting; provide default values logically.<\/li>\n  <li><strong>Scaling<\/strong> Simplify: Less replication lag and predictable deployments.<\/li>\n<\/ul>\n\n<p>These points only really come into play when I check for compatibility issues\u2014such as ROW_FORMAT or special indexes\u2014and verify them through testing. This way, I keep changes to large tables manageable and remain in control even during peak loads. <strong>capable of acting<\/strong>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/mariadb-schemaaenderung-1456.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Why Instant ADD COLUMN Changes the Rules of the Game<\/h2>\n\n<p>In the past, a classic <code>ALTER TABLE ... ADD COLUMN<\/code> frequent copy jobs lasting hours, locks that cause system freezes, and noticeable <strong>Downtime<\/strong>. This didn't work well with agile releases and 24\/7 applications, where every maintenance window is costly. With the INSTANT algorithm, the workload shifts from the data layer to the catalog layer, making changes extremely fast\u2014even with billions of rows. I can deploy new attributes live without interrupting the running workload. This gives me the flexibility for rapid iterations and <strong>Release<\/strong>-Clocking.<\/p>\n\n<p>From an operational perspective, risks and coordination efforts are reduced because I no longer have to plan major system changes. This approach directly impacts replication, backup windows, and application operations. Where a team used to coordinate overnight operations, a quick change with a well-defined rollout plan is often all that\u2019s needed today. This allows me to test product ideas faster and bring them online. As a result, database maintenance becomes a <strong>Growth levers<\/strong>.<\/p>\n\n<h2>Here's how the INSTANT algorithm works behind the scenes<\/h2>\n\n<p>The basic idea is simple: InnoDB extends the table definition and adds a special entry to the clustered index, rather than physically accessing each row. This makes new columns exist logically, and when reading, the engine returns either the default value or a stored <strong>Value<\/strong>. This change takes O(1) time relative to the number of records, because no pages are rewritten. Secondary indexes remain unchanged, which avoids additional I\/O. I benefit from the shortest locks, minimal I\/O, and very small <strong>Transactions<\/strong>.<\/p>\n\n<p>As soon as I write data to the new column, InnoDB persists these values as usual. Until then, it\u2019s merely a virtual expansion of the structure. That\u2019s exactly why many production schemas can be extended without disrupting operations. I keep in mind that certain combinations of formats and features can prevent instant. A quick check beforehand saves me from having to <strong>Surprises<\/strong>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/mariadb_schema_aenderung_2843.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Versions, Formats, and Limits<\/h2>\n\n<p>In MariaDB 10.3, I can only add the new column instantly at the end of the table; if I specify a position, the operation falls back to a slower algorithm. Starting with MariaDB 10.4, an extended data format allows insertions at almost any position, instant `DROP COLUMN`, and changes to the column order. Certain row formats, such as <code>ROW_FORMAT=COMPRESSED<\/code>, and special indexes can cause restrictions. I also check whether <code>innodb_instant_alter_column_allowed<\/code> limits its behavior. Only when the version, format, and variables match does INSTANT give me the result I was hoping for <strong>Benefit<\/strong>.<\/p>\n\n<p>A quick reality check can help: <code>SELECT VERSION();<\/code>, <code>SHOW CREATE TABLE ...;<\/code> and a dry <code>ALTER TABLE ... ADD COLUMN ... ALGORITHM=INSTANT, LOCK=NONE;<\/code> on the staging environment. If I see an error message, I block the production change and adjust the design or options. This way, I prevent unintended rebuilds and the resulting traffic spikes. This preliminary check really pays off, especially with very large tables. I\u2019d rather make that decision in the test environment than under <strong>Production Printing<\/strong>.<\/p>\n\n<h2>Limits in Detail: Data Types, Defaults, and Special Cases<\/h2>\n\n<p>For INSTANT to work, split definitions must follow certain rules. The following rule of thumb has proven effective: <strong>Simple, consistent defaults<\/strong> work, but complex expressions often don't. So I set <code>DEFAULT NULL<\/code> or a clear literal value (number, string), but avoid function calls such as <code>NOW()<\/code>, <code>UUID()<\/code> or dependent expressions. For text- and blob-like types, additional restrictions apply depending on the version; I don't rely on gut feelings, but rather test using a realistic staging dump.<\/p>\n\n<p>Not every attribute type is suitable for an \u201einstant\u201c start: A column with <code>AUTO_INCREMENT<\/code> introduce, and also right away a <strong>Unique Index<\/strong> build it or place it directly in a <strong>Foreign Key<\/strong> Using this approach quickly takes you off the instant path. In such cases, I break the change down into several steps: first the column (INSTANT), then the index\/constraint (typically INPLACE). <strong>Generated<\/strong> or <strong>virtual<\/strong> I check columns separately; different algorithms are used depending on the output and the engine. Character set and <strong>collation<\/strong> I explicitly specify this to prevent any surprises later on when sorting or comparing.<\/p>\n\n<p>Also <strong>Changes in Position<\/strong> remain version-dependent: In 10.3, I have to place columns at the end; starting with 10.4, I have almost complete freedom. Nevertheless, I pay attention to ORMs and tools that address columns by ordinal position\u2014in those cases, even a shift without copying the data can cause logical errors. So I plan the position not only from a technical standpoint but also with the application code in mind.<\/p>\n\n<h2>Best Practices: Secure Implementation<\/h2>\n\n<p>I always write DDL statements explicitly to avoid ambiguous fallbacks. With <code>ALGORITHM=INSTANT<\/code> and <code>LOCK=NONE<\/code> I force MariaDB to use the fast option, or I get a clear error. Does the column <code>NOT NULL<\/code>, I set a reasonable default so that old lines are logically correct <strong>Values<\/strong> deliver. Before the rollout, I measure latencies, replication behavior, and lock durations on the staging environment. I also clearly document the change in the change log of the <strong>Database<\/strong>.<\/p>\n\n<p>Useful examples are helpful in practice: <code>ALTER TABLE orders ADD COLUMN marketing_tag VARCHAR(40) DEFAULT '' NOT NULL ALGORITHM=INSTANT, LOCK=NONE;<\/code>. Or for 10.4+: <code>ALTER TABLE users ADD COLUMN plan INT DEFAULT 0 NOT NULL AFTER status ALGORITHM=INSTANT, LOCK=NONE;<\/code>. In both cases, I first check the table options to ensure a compatible ROW_FORMAT. During execution, I monitor metrics such as Threads_running and I\/O. After the change, I verify queries that immediately use the new column <strong>use<\/strong>.<\/p>\n\n<h2>Reliable Migration Patterns Using Backfill and Indexes<\/h2>\n\n<p>In production environments, I work with <strong>two-stage<\/strong> Changes. Step 1: Add a column named \"instant,\" first <code>NULL<\/code>-capable and with a clear default. Step 2: Update the application via a feature flag so that new write operations already populate the column, while existing data remains empty. The <strong>Backfill<\/strong> I run it asynchronously in small batches, e.g., using a worker that uses <code>UPDATE ... WHERE new_col IS NULL ORDER BY pk LIMIT N<\/code> iterates and inserts pauses between runs. This keeps the load manageable.<\/p>\n\n<p>If I need a secondary index on the new column, I decouple it from the column addition. Index creation is usually <strong>INPLACE<\/strong>, but it takes time proportional to the amount of data. By decoupling these processes, I prevent the quick schema change from failing due to lengthy index runs. Only after the backfill is complete do I optionally run a <code>NOT NULL<\/code>-Step by step\u2014but only if the algorithm allows it without a rebuild. For rollbacks, it\u2019s often sufficient to toggle the feature flag back off and leave the column unused until a clean rollback is scheduled.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/mariadb-schema-change-downtime-f5b7.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Performance and Replication<\/h2>\n\n<p>Instant operations reduce the workload that replicas must handle because there are no large-scale copy operations. This lowers the risk of noticeable lag and reduces the load on concurrently running <strong>Queries<\/strong>. In environments with multiple sites or cascades, this plays a crucial role in meeting RTO\/RPO targets. Who can find suitable <a href=\"https:\/\/webhosting.de\/en\/database-replication-topologies-hosting-cluster-setup-database-scaling\/\">Replication Topologies<\/a> can pass along changes in a targeted manner and clearly structure rollbacks. This ensures that the system remains stable even during traffic spikes <strong>responsive<\/strong>.<\/p>\n\n<p>Nevertheless, I pay attention to binlog formats and event sizes to avoid side effects. When write volumes are very high, I monitor slave status and SQL thread latency during the change. If auditing is required, the DDL change can be highlighted in log tagging. Downstream ETL jobs should be made aware of the new column early on so that no nightly runs end up processing empty data. This orchestration ensures reliable <strong>Processes<\/strong>.<\/p>\n\n<h2>Galera\/Cluster Specifics for Instant DDL<\/h2>\n\n<p>In synchronously replicating clusters (e.g., Galera), DDL operations often act as <strong>TOI<\/strong>-Event (Total Order Isolation). INSTANT significantly reduces the global coordination required for this, but a brief cluster-wide pause may still occur. I therefore continue to plan such changes carefully, keep sessions short, and avoid concurrent, long-running transactions that <strong>MDL<\/strong>-could extend lock-in periods. I only use RSU (Rolling Schema Upgrade) strategies in specific cases when they are technically necessary\u2014the operational overhead is usually greater than the benefit.<\/p>\n\n<p>Especially important: Schema and application rollouts <strong>orchestrate<\/strong> I make sure that all nodes have a consistent view before peak loads occur. I prevent health checks and readiness probes by using short maintenance windows and clear abort criteria. This ensures that the <strong>Availability<\/strong> high, despite global DDL serialization.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/MariaDB_Schemaaenderungen1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Planning for Hosting Setups<\/h2>\n\n<p>In managed or cluster setups, Instant-DDL really shines because I no longer have to schedule deployments around long maintenance windows. Especially with SSD storage and high parallelism, I reduce I\/O spikes and <strong>Cache<\/strong>. I coordinate changes with application deployments so that feature flags and schema changes are activated in sequence. Monitoring remains active, but manual intervention is required less often. The result is clearer plans and fewer operational <strong>Risks<\/strong>.<\/p>\n\n<p>I also take backup schedules and ongoing batch jobs into account to ensure the change doesn\u2019t fall between major reports. In multi-tenant scenarios, I coordinate whether certain databases are updated first and others follow. I ensure consistency by maintaining uniformity in configurations such as ROW_FORMAT. This helps me avoid surprises if additional columns are needed later on. Planning makes a noticeable difference here. <strong>Expenditure<\/strong>.<\/p>\n\n<h2>Practical Examples from Projects<\/h2>\n\n<p>A store needs a customer segment field on short notice for a campaign; I add the column using INSTANT, and the marketing team can populate it immediately. A log table records new technical parameters; I add the column during the day while hundreds of write operations per second continue to run and the application <strong>answers<\/strong>. In a reporting system, I can add additional KPI fields without compromising daily closings. Regulatory requirements can also be implemented more quickly when audit fields are added without requiring a rebuild. These small changes deliver quick <strong>Results<\/strong>.<\/p>\n\n<p>In all cases, I then check the statistics and review specific samples. I check whether ORMs or migration tools take the column into account immediately. Caches and migration scripts must be aware of the new structure to prevent misinterpretations. For larger teams, I document the change in a runbook. This ensures that the history and rationale for the decision are clearly documented. <strong>comprehensible<\/strong>.<\/p>\n\n<h2>Troubleshooting When It's Not Instant<\/h2>\n\n<p>If a change collides with <code>ALGORITHM=INSTANT<\/code> , I first check for incompatible formats such as <code>ROW_FORMAT=COMPRESSED<\/code> or by special indexes. Then I check the version details: In 10.3, the column position forces the <strong>End<\/strong>, starting April 10, things will be more flexible. If the database falls back to INPLACE or COPY, I'll abort the operation and adjust the strategy or schema. The following are significant: <code>SHOW WARNINGS<\/code> and <code>SHOW CREATE TABLE<\/code> for layout indicators. Only once the test case works instantly will I plan the production deployment <strong>Execution<\/strong>.<\/p>\n\n<p>I also consider periods with high transaction volumes: Even brief metadata locks can cause issues in hotspots if applications exhibit unfavorable patterns. By planning more carefully to target a quieter time window, I can mitigate these effects. I also check whether triggers, virtual columns, or foreign keys have side effects. Thorough checks up front save a lot of time in the event of an incident. My goal remains to keep the change brief, reversible, and <strong>transparent<\/strong> to hold.<\/p>\n\n<h2>Monitoring and Troubleshooting During Operation<\/h2>\n\n<p>During the rollout, I focus specifically on observing <strong>MDL<\/strong>-Wait times and I\/O. <code>INFORMATION_SCHEMA.PROCESSLIST<\/code> and <code>INFORMATION_SCHEMA.METADATA_LOCKS<\/code> show me whether sessions are waiting for DDL. In addition, I use <strong>performance_schema<\/strong>-Events to track short pauses. On replicas, I check SQL thread latency and Seconds_Behind_Master so that I can throttle backfills or app deployments if necessary. The binlog grows only minimally with INSTANT; outliers indicate hidden follow-up steps (e.g., index creation).<\/p>\n\n<p>After the change, I validate using <code>EXPLAIN<\/code> and sample reads to ensure that queries correctly recognize the new columns. In dashboards, I observe <strong>Threads_running<\/strong>, handler counters, and buffer pool hit rate, to identify side effects. If, despite <code>LOCK=NONE<\/code> When lockups occur, it's usually due to a competing DDL or DML hotspot. In that case, a short maintenance window or rescheduling for a quieter period can help. I deliberately abort errors rather than resorting to unclear fallbacks\u2014this saves me from having to perform tedious rebuilds.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/entwicklerdesk_mariadb_1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Comparison of DDL Algorithms<\/h2>\n\n<p>The following overview categorizes COPY, INPLACE, and INSTANT and helps me realistically assess risks and duration. I also evaluate the extent to which concurrent access is affected and what locks may occur. For a deeper understanding of locks, it\u2019s worth taking a look at <a href=\"https:\/\/webhosting.de\/en\/database-row-locking-mysql-concurrency-optimization-performance-locks\/\">Row Locking<\/a> and the impact on parallelism. This is how I avoid making the wrong decisions when it comes to production-critical <strong>tables<\/strong>. The table has been intentionally kept concise and serves as a quick <strong>Comparison<\/strong>.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Algorithm<\/th>\n      <th>Locks<\/th>\n      <th>Data Copy<\/th>\n      <th>Duration (large tables)<\/th>\n      <th>Typical use<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>COPY<\/td>\n      <td>stronger <strong>Locks<\/strong><\/td>\n      <td>complete<\/td>\n      <td>long (up to hours)<\/td>\n      <td>Incompatible changes, format changes<\/td>\n    <\/tr>\n    <tr>\n      <td>INPLACE<\/td>\n      <td>moderate <strong>Locks<\/strong><\/td>\n      <td>partially\/metadata-heavy<\/td>\n      <td>moderate (minutes or longer)<\/td>\n      <td>Many online changes without a complete rebuild<\/td>\n    <\/tr>\n    <tr>\n      <td>INSTANT<\/td>\n      <td>short <strong>MDL<\/strong>-phases<\/td>\n      <td>No (metadata only)<\/td>\n      <td>very short (ms to s)<\/td>\n      <td>ADD\/DROP COLUMN, Column Reordering (Starting with 10.4)<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<p>I interpret the table as a decision tree: If INSTANT is possible, I use it; if not, I consider INPLACE; only if both fail do I accept COPY. The combination of LOCK strategy and algorithm must match the traffic pattern. Especially with applications that involve heavy writing, I ensure a fallback option in advance. This way, deployments remain stable even under pressure. <strong>controllable<\/strong>. If I apply this consistently, I'll save a lot <strong>Time<\/strong>.<\/p>\n\n<h2>Application Compatibility and ORMs<\/h2>\n\n<p>Schema changes are \u201einvisible\u201c only if the application code can handle them. <strong>SELECT *<\/strong> and ordinal position accesses become risk factors as soon as I reorder columns (starting with 10.4) or insert new fields. I therefore prefer explicit column lists, validated mappings, and versioning of DTOs. ORMs and migration runners often cache metadata; a warm restart or a \u201ereprepare\u201c for prepared statements prevents misinterpretations. In microservice environments, I coordinate releases so that only compatible versions handle traffic at the same time.<\/p>\n\n<p>When it comes to backward compatibility, here\u2019s my approach: First, add a column; then roll out code that optionally uses it; only once all instances have been updated and the backfill is complete do I tighten the constraints. This keeps rollbacks and rollforwards fast and ensures the system remains robust. For audits, I document the rationale, SQL statement, timing, success criteria, and rollback procedure\u2014this builds trust and ensures repeatability. <strong>Processes<\/strong>.<\/p>\n\n<h2>Scaling: Partitioning and Instant DDL<\/h2>\n\n<p>Partitioning and INSTANT complement each other perfectly because smaller physical units make updates even more predictable. When I split tables logically, I limit hotspots and make future modifications easier. Good <a href=\"https:\/\/webhosting.de\/en\/database-partitioning-strategies-hosting-scalable-databases\/\">Partitioning Strategies<\/a> help keep very large datasets manageable over the long term. Overall, I achieve lower latency, clearer maintenance windows, and less risk when <strong>Changes<\/strong>. The new column will then be available more quickly on all relevant partitions.<\/p>\n\n<p>I plan the sequence: first, the partitioning design; then the DDLs; then backfills for optional values. This way, I eliminate conflicts that could arise from simultaneous index or storage adjustments. Here, too, testing remains my most powerful tool. With clear metrics, I can determine whether a step is viable on production systems. This disciplined approach saves trouble and keeps the team <strong>concentrated<\/strong>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/mariadb-schemawechsel-1832.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Crash Recovery, Backups, and Consistency<\/h2>\n\n<p>INSTANT-DDL only changes <strong>Catalog and Metadata<\/strong>. This makes the operation fast\u2014and atomic. After a crash, the column is either visible or not at all; there is no \u201ein-between state.\u201c The load on the redo\/undo log remains minimal because no data pages are moved. For replication: The DDL event is passed on cleanly; replicas do not need to copy any rows. Physical backups running during the change should capture the brief metadata change at the snapshot point\u2014tools with consistent checkpointing can handle this. Logical backups immediately include the column in <code>CREATE TABLE<\/code>-instructions, even though many lines still contain the <strong>Default<\/strong> carry.<\/p>\n\n<p>It is possible to make several consecutive instant changes. However, I am careful not to change positions or drop and recreate columns arbitrarily often. Frequent structural changes increase the coordination effort and, in extreme cases, can eventually make a complete rebuild necessary (e.g., when format changes are required). With a pragmatic change window and a clear roadmap, I keep technical debt in check.<\/p>\n\n<h2>Briefly summarized<\/h2>\n\n<p>With Instant ADD COLUMN, I can make schema changes to large tables in real time by modifying only the metadata and leaving the data blocks untouched. The correct version, a compatible ROW_FORMAT, and clear DDL options such as <code>ALGORITHM=INSTANT<\/code> and <code>LOCK=NONE<\/code> determine whether the system succeeds or needs to be rebuilt. For operations and replication, this means less latency, predictable deployments, and high <strong>Availability<\/strong>. I use testing, monitoring, and thorough documentation to avoid surprises. This keeps my database flexible, and I can roll out new requirements without any downtime in the <strong>Live operation<\/strong> from.<\/p>","protected":false},"excerpt":{"rendered":"<p>Discover how MariaDB Instant ADD COLUMN enables schema changes without downtime thanks to the INSTANT algorithm and is revolutionizing database administration with MariaDB online DDL.<\/p>","protected":false},"author":1,"featured_media":21224,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[781],"tags":[],"class_list":["post-21231","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-datenbanken-administration-anleitungen"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"109","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"Instant ADD COLUMN","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"21224","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/posts\/21231","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/comments?post=21231"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/posts\/21231\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/media\/21224"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/media?parent=21231"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/categories?post=21231"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/tags?post=21231"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}