Peter Hoffmann

Garmin inReach Mini 2 Leaflet checkin map

2026-02-13T00:00:00Z

We will be trekking the eastern part of the Great Himalaya Trail in Nepal in March/April. Details on the route and our plans can be found at https://greathimalayatrail.de. Our intent is to keep friends and family updated on our progress. Given that we'll be hiking in quite remote areas, a satellite phone/pager will be our sole means of communication.

After the Garmin inReach Mini 3 was released recently, the Inreach Mini 2 was on heavy sale. The inReach Mini 2 has all the features I need: satellite messaging, check-ins, offline mode with navigation, and track recording.

Plans

I'm on the Garmin Essential plan for 18 euros per month. It includes 50 free text messages or weather requests each month, plus unlimited check-in messages. The smaller Enabled plan (10 Euros) is missing the unlimited checkins, while the the Standard plan (34 Euros) gives you 150 free messages and unlimited live tracking. More details are on the Garmin page

Messaging

There are three different type of messages that you can send:

Check-In Messages: There are three preset messages. You can configure the recipients at explore.garmin.com. Depending on your Garmin subscription, sending check-in messages are free of charge. In the configuration section, you can enable the option to include your latitude/longitude and a link to the Garmin map in each SMS message. This information is always included for email recipients

Quick Messages: You can create up to 20 predefined messages so you don’t have to type them while you’re on the trail. The number of free messages you get depends on your Garmin subscription; any additional messages are billed per use. You can create or edit these messages at explore.garmin.com.

Normal Messages: In the Garmin Messenger iPhone app, you can type any custom message and send it to both SMS and email recipients. These messages are billed the same way as quick messages.

You can configure the system to send all messages to any email/sms recipients. The great thing is that the unlimited check-in messages also include latitude/longitude information. Here is a sample message.

Arrived at Camp

View the location or send a reply to Peter Hoffmann:
https://inreachlink.com/<unique_code>

Peter Hoffmann sent this message from: Lat 48.996386 Lon 8.468849

Do not reply directly to this message.

This message was sent to you using the inReach two-way satellite communicator with GPS. To learn more, visit http://explore.garmin.com/inreach.

As we do not want to spam all our friends with daily checkins I have build a little leaflet-checkin plugin and an imap scraper to pull and visualize the checkin/messages.

Build your own Tracking with Check-In Messages

For battery life reasons, we are not interested in real-time live tracking.
Instead, I’ve created a small script that checks a dedicated IMAP email account for check-in messages and publishes them to a server, which then displays the location of our most recent check-in. Sending a check-in once a day or during each break when we are in more remote areas—should give our friends enough information in case any problems arise.

A straightforward Python script connects to my IMAP server, retrieves all emails from the Garmin InReach service, parses the message, timestamp, and latitude/longitude, and then updates a positions.json file on my webserver.

Then a simple static html file with a leaflet map pulls the positions.json file and displays the messages/checkins on the map.

A demo of the map is available at:

https://hoffmann.github.io/garmin-inreach-checkin-map/html/map.html

and you can checkout the code

https://github.com/hoffmann/garmin-inreach-checkin-map

#!/usr/bin/env python3
"""Poll IMAP inbox for Garmin inReach emails and extract positions into positions.json."""

import email
import email.utils
import imaplib
import json
import os
import re
import sys
from datetime import datetime, timezone

BOILERPLATE_PREFIXES = (
    "View the location",
    "Do not reply",
    "This message was sent",
)

POSITIONS_FILE = os.path.join(
    os.path.dirname(os.path.abspath(__file__)), "positions.json"
)


def connect(host, user, password):
    imap = imaplib.IMAP4_SSL(host)
    imap.login(user, password)
    return imap


def search_inreach_emails(imap):
    imap.select("INBOX")
    status, data = imap.search(
        None, '(OR FROM "no.reply.inreach@garmin.com" SUBJECT "inReach message")'
    )
    if status != "OK":
        return []
    msg_ids = data[0].split()
    return msg_ids


def get_text_body(msg):
    if msg.is_multipart():
        for part in msg.walk():
            if part.get_content_type() == "text/plain":
                charset = part.get_content_charset() or "utf-8"
                return part.get_payload(decode=True).decode(charset)
    else:
        charset = msg.get_content_charset() or "utf-8"
        return msg.get_payload(decode=True).decode(charset)
    return ""


def parse_timestamp(msg):
    date_str = msg.get("Date")
    if not date_str:
        return None
    dt = email.utils.parsedate_to_datetime(date_str)
    dt_utc = dt.astimezone(timezone.utc)
    return dt_utc.strftime("%Y-%m-%dT%H:%M:%SZ")


def parse_body(body):
    lines = body.strip().splitlines()

    # Extract message: first non-empty line
    message = ""
    for line in lines:
        stripped = line.strip()
        if stripped:
            message = stripped
            break

    # Check if the message is boilerplate
    if any(message.startswith(prefix) for prefix in BOILERPLATE_PREFIXES):
        message = ""

    # Extract lat/lon
    lat, lon = None, None
    m = re.search(r"Lat\s+([-\d.]+)\s+Lon\s+([-\d.]+)", body)
    if m:
        lat = float(m.group(1))
        lon = float(m.group(2))

    return message, lat, lon


def parse_email(msg_data):
    msg = email.message_from_bytes(msg_data)

    timestamp = parse_timestamp(msg)
    if not timestamp:
        return None

    body = get_text_body(msg)
    if not body:
        return None

    message, lat, lon = parse_body(body)
    if lat is None or lon is None:
        return None

    entry = {
        "timestamp": timestamp,
        "lat": lat,
        "lon": lon,
    }
    if message:
        entry["msg"] = message
    

    return entry


def load_positions():
    if os.path.exists(POSITIONS_FILE):
        with open(POSITIONS_FILE) as f:
            return json.load(f)
    return []


def save_positions(positions):
    with open(POSITIONS_FILE, "w") as f:
        json.dump(positions, f, indent=2)
        f.write("\n")


def main():
    host = os.environ.get("IMAP_HOST")
    user = os.environ.get("IMAP_USER")
    password = os.environ.get("IMAP_PASSWORD")

    if not all([host, user, password]):
        print("Error: Set IMAP_HOST, IMAP_USER, and IMAP_PASSWORD environment variables.")
        sys.exit(1)

    imap = connect(host, user, password)
    try:
        msg_ids = search_inreach_emails(imap)
        print(f"Found {len(msg_ids)} inReach email(s)")

        new_entries = []
        for msg_id in msg_ids:
            status, data = imap.fetch(msg_id, "(RFC822)")
            if status != "OK":
                continue
            entry = parse_email(data[0][1])
            if entry:
                new_entries.append(entry)
    finally:
        imap.logout()

    existing = load_positions()
    existing_timestamps = {p["timestamp"] for p in existing}

    added = 0
    for entry in new_entries:
        if entry["timestamp"] not in existing_timestamps:
            existing.append(entry)
            existing_timestamps.add(entry["timestamp"])
            added += 1

    existing.sort(key=lambda p: p["timestamp"])
    save_positions(existing)

    print(f"Added {added} new position(s) ({len(existing)} total)")


if __name__ == "__main__":
    main()

Local macOS Dev Setup: dnsmasq + caddy-snake for python projects

2026-02-05T00:00:00Z

When working on a single web project, running flask run on a fixed port is usually more than sufficient. However, as soon as you start developing multiple services in parallel, this approach quickly becomes cumbersome: ports collide, you have to remember which service runs on which port, and you end up constantly starting, stopping, and restarting individual development servers by hand.

Using a wildcard local domain (*.lan) throuhg dnsmask and a vhost proxy with proper WSGI services solves these problems cleanly. Each project gets a stable, memorable local subdomain instead of a port number, services can run side by side without collisions, and process management becomes centralized and predictable. The result is a local development setup with less friction.

dnsmasq on macOS Sonoma (Local DNS with `.lan`)

This is a concise summary of how to install and configure dnsmasq on macOS Sonoma to resolve local development domains using a .lan wildcard (e.g. *.lan → 127.0.0.1).

1. Install dnsmasq

Using Homebrew:

brew install dnsmasq

Homebrew (on Apple Silicon) installs dnsmasq and places the default config in:

/opt/homebrew/etc/dnsmasq.conf

2. Configure dnsmasq

Edit the configuration file:

sudo vim /opt/homebrew/etc/dnsmasq.conf

Add the following:

# Listen only on localhost
listen-address=127.0.0.1
bind-interfaces

# DNS port
port=53

# Wildcard domain for local development
address=/.lan/127.0.0.1

This maps any *.lan hostname to 127.0.0.1.

It's recommended to not use .dev as this is real Google owned TLD and browsers have baked in to use HTTPS only. Also don't use .local as this is reserved for mDNS (Bonjour).

3. Tell macOS to use dnsmasq

macOS ignores /etc/resolv.conf, so DNS must be configured per network interface.

Option A: System Settings (GUI)

System Settings → Network
Select your active interface (Wi-Fi / Ethernet)
Details → DNS
Add:
```
127.0.0.1
```
Move it to the top of the DNS server list

Option B: Command line

networksetup -setdnsservers Wi-Fi 127.0.0.1

(Replace Wi-Fi with the correct interface name if needed.)

4. Start dnsmasq

Run it as a background service:

sudo brew services start dnsmasq

Or run it manually for debugging:

sudo dnsmasq --no-daemon

5. Flush DNS cache

This step is required on Sonoma:

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

6. Test

dig foo.lan
ping foo.lan

Both should resolve to:

127.0.0.1

Result

You now have:

dnsmasq running on 127.0.0.1
Wildcard local DNS via *.lan
Fully compatible behavior with macOS Sonoma

Caddy

Note: My initial plan was to use caddy with caddy-snake to run multiple vhosts for python wsgi apps with the configuration below. But this did not work out as expected because caddy-snake does not run multiple python interpreters for the different projects, but only appends the site packages from the python projects to sys.path for all projects and runs all of them in the same python interpreter. This leads to problems with different python versions or incompatible python requirements installed in the different venv versions. So the approach below only works if you use the same python version and your requirements are compatible within the different apps.

Caddyfile: host multiple WSGI services

As we want caddy to run wsgi services we need to build caddy-snake:

The caddyfile now needs to be stored in $(brew --prefix)/etc/Caddyfile

{
    auto_https off
}

http://foo.lan {
    bind 127.0.0.1
    route {
        python {
            module_wsgi app:app
            working_dir /Users/you/dev/foo
            venv /Users/you/dev/foo/.venv
		}
	}

    log {
        output stdout
        format console
    }
}

http://bar.lan {
    bind 127.0.0.1 
    route {
        python {
            module_wsgi app:app
            working_dir /Users/you/dev/bar
            venv /Users/you/dev/bar/.venv
        }
    }
}

Update

Miguel, the author of caddy-snake reached out, recently he released a new version of caddy-snake that allows dynamic modules, it will make the local dev setup much easier, one can now write something like this:

{
    auto_https off
}

http://*.lan {
    bind 127.0.0.1
    route {
        python {
            module_wsgi app:app
            working_dir /Users/you/dev/{http.request.host.labels.2}
            venv /Users/you/dev/{http.request.host.labels.2}/.venv
	}
     }

    log {
        output stdout
        format console
    }
}

Now it's possible to select working dir and venv based on portions of the host used in the request, which means you can have a single caddyfile, that you don't need to modify, for all your apps.

This is possible thanks to added support for caddy placeholders.

Georg Bayerle - Der Alpen Appell

2025-09-30T00:00:00Z

In seinem Buch Der Alpen Appell schildert Georg Bayerle eindrucksvoll anhand von vielen Beispielen, wie der Klimawandel und die zunehmende touristische sowie wirtschaftliche Erschließung den Naturraum Alpen verändern und belasten.

Die rhetorische Frage "Dürfen wir jetzt noch Ski fahren?" beantwortet Georg Bayerle wie folgt:

Natürlich dürfen wir. Dieses Buch möchte vielmehr bewirken, dass Skifahren noch lange erhalten bleibt, indem sich der Skisport und wir alle besser an die Natur und die natürlichen Bedingungen anpassen. Dazu gehört, den Klimawandel nicht mit immer noch größerem Ressourceneinsatz anzuheizen, indem wir dessen Folgen bekämpfen, sondern sich auf die Veränderungen einzulassen.

Die Alpen sind seit jeher Sehnsuchtsort, Rückzugsraum und Sinnbild für Ursprünglichkeit. Doch was passiert, wenn dieser natürliche Raum – dieses fragile Ökosystem – zunehmend unter der Last von Tourismus, Erschließung und Klimawandel ächzt? In Georg Bayerles Streitschrift "Der Alpen-Appell" schlägt der Autor einen ehrlichen, mahnenden Ton an: Die Alpen dürfen nicht zum „Funpark“ verkommen. Vielmehr muss ein Umdenken einsetzen, um die Berge für kommende Generationen zu bewahren.

Das Buch ist keine theoretische Abhandlung, sondern stellt eine engagierte und sehr konkrete Bestandsaufnahme dar: Bayerle kombiniert persönliche Beobachtungen mit Fallbeispielen, Fachrecherchen und reflektierenden Überlegungen. Er zeigt auf, wie der wirtschaftliche Druck, touristische Begehrlichkeiten und klimatische Veränderungen zusammen unsere Alpenlandschaft und ihre Strukturen verändern.

Fragiles Gleichgewicht unter Druck Bayerle macht darauf aufmerksam, dass viele alpine Lebensräume bereits an ihre Belastungsgrenzen stoßen – ob durch Bodenversiegelung, Ausbau von Liftanlagen, Straßen, Schneekanonen oder Speicherseen. Besonders problematisch, so Bayerle, ist es, wenn technische Lösungen zur Norm werden und natürliche Bedingungen damit außer Kraft gesetzt werden. So bemerkt er, dass künstlich produzierter Schnee oft als natürlich wahrgenommen wird und Speicherbecken wie "Kopien" von Bergseen inszeniert werden, ohne Rücksicht auf die dabei verursachten Eingriffe.

Konfliktfeld Erschließung vs. Schutz Ein wiederkehrendes Thema ist der Ausbau von Seilbahnen, Liften und infrastruktureller Erschließung – insbesondere in fragilen Gebieten. Bayerle kritisiert, dass trotz langjähriger Forderungen, zum Beispiel von Alpenvereinen und der Alpenschutzorganisation CIPRA, oft weitergebaut wird. Beispiele hierfür sind Tirol oder das Grenzgebiet zwischen dem Ötztal und dem Pitztal.

Er zeigt zudem auf, wie manche Skigebiete in ihrer Ausgestaltung bereits in den Bereich von Freizeitparks oder Themendörfern übergehen – mit all den infrastrukturellen Eingriffen, die damit verbunden sind.

Konkrete Lösungsansätze und Reflexionen Bayerle beschränkt sich jedoch nicht auf reine Anklagen – er sucht nach Orientierungshilfen für eine nachhaltigere Zukunft. Er verweist auf Initiativen wie die Bergsteigerdörfer, den Ansatz der „Alpine Pearls“ oder Modelle des sanften Tourismus, die das Ziel verfolgen, Natur- und Erlebnisraum in Einklang zu bringen.

Zentral ist dabei der Appell an mehr Achtsamkeit – sowohl bei Gästen als auch bei Einheimischen und Entscheidungsträgern. Denn nur ein sensiblerer Umgang mit den Landschaften bietet die Chance, Erholung und Nachhaltigkeit miteinander zu verbinden.

Weiterführendes Material

Bergauf Bergab: Kraftwerk Kühtai: Das Längental wird zum Speichersee

Im Bergauf-Bergab-Beitrag wird eindrücklich gezeigt, wie alpiner Raum durch Wasserkraftprojekte und Speicherbecken verändert wird.

https://www.youtube.com/watch?v=xHuYMXcCBW8

Alexander Schiebel: Das Wunder von Mals

Die Dokumentation schildert, wie eine Gemeinde gegen Pestizide und industrielle Landwirtschaft kämpft – ein Beispiel, wie lokale Selbstbestimmung gegen externe ökonomische Interessen wirken kann.

https://www.youtube.com/watch?v=HUoluVn7xbI

Alpenverein Basecamp Podcast: #050 Der Alpen-Appell: Wie retten wir die Alpen?

Unsere Jubiläumsfolge haben wir am Alpenklimagipfel direkt am Gipfel der Zugspitze aufgenommen. Auf 2.962 Metern diskutieren der preisgekrönte Umweltjournalist Georg Bayerle und der Gletscherbahn-Manager Reinhard Klier über die Zukunft der Alpen. Wie können wir das Gleichgewicht zwischen Erleben und Erhalten, zwischen Wirtschaft und Wildnis neu austarieren?

Reinhard Klier: Geologe, Vorstand der Wintersport Tirol AG und Obmann der Fachgruppe Seilbahnen in der Wirtschaftskammer Tirol. Vertritt rund 600 Mitarbeiter:innen und sieht in der Erschließung auch Verantwortung, Arbeitsplätze und regionalen Zusammenhalt.

https://alpenverein-basecamp.podigee.io/50-alpen-appell

Bergauf Bergab: Pitztal und Ötztal: Bedrohte Winterparadiese

Obwohl die Alpenvereine und auch die Internationale Alpenschutzkommission Cipra schon seit Jahren einen Erschließungsstopp in den Alpen fordern, geht der Ausbau der Seilbahnen und Lifte weiter – ganz besonders intensiv in unserem Nachbarland Tirol. Besonders große Aufregung ruft derzeit die so genannte „Gletscherehe“ zwischen dem Ötztal und dem Pitztal hervor. Dabei geht es um das Gebiet um den Linken Fernerkogel und die Braunschweiger Hütte, sehr bekannt, weil im Sommer der Europäische Fernwanderweg E5 hindurchführt – ein Gelände, das komplett mit Liften erschlossen werden würde. Georg Bayerle hat sich das Gebiet, um das es geht, genau angesehen und wirft aus bergsteigerischer Perspektive einen Blick auf die Erschließungspläne!Welchen Wert wilde und unberührte Gegenden haben, zeigt ein zweiter Beitrag, bei dem "Bergauf-Bergab" eine Gruppe junger Snowboarderinnen und Snowboarder in die Leventina begleitet hat, eine einsame Gegend in der Schweiz südlich des Gotthard-Tunnels.

https://www.ardmediathek.de/video/Y3JpZDovL2JyLmRlL3ZpZGVvLzM4NjBjNGFjLWNiNjAtNDhjZS05OTJjLWQ5M2Y0YzE1ZDE3Mg

ARD Radiofeature: Der Alpenkollaps - Der Journalist Georg Bayerle im Gespräch

Die Olympischen Winterspiele 2026 in den italienischen Dolomiten sollen klimafreundlich und nachhaltig werden, versprechen die Organisatoren. Doch es droht ein Desaster: Kunstschnee, Straßenbau und Massentourismus. Dabei sorgt der Klimawandel schon jetzt für Gletscherschmelze, Sturzfluten und Felsabbrüche in den Alpen. BR-Journalist und Bergkenner Georg Bayerle hat mehr als ein Jahr zu den Vorgängen recherchiert. Im Podcast mit Palina Milling erzählt er über die Zivilcourage der Bewohner, die Ignoranz der Funktionäre und die Ideen, wie man Sportveranstaltungen nachhaltig und umweltverträglich gestalten kann

https://www.ardaudiothek.de/episode/urn:ard:section:9ffc2a089a9fcd14/

Tagesschau Podcast: Zukunft der Alpen: Wie das Klima Berge bröckeln lässt

Das Leben in den #Alpen war noch nie ungefährlich. Die Naturgewalt der Berge prägt die Menschen und ihren Alltag dort seit jeher. Doch die Schlagzahl und Intensität von #Bergstürzen, Schlammlawinen und Muren hat durch die Klimaerwärmung zugenommen und macht das Leben in den Bergen gefährlicher. BR-Journalist und Bergexperte Georg Bayerle erzählt in dieser Folge von Einheimischen, deren Heimat verschwindet und Forschenden, die nach Mitteln und Wegen suchen, die Gefahr in Zukunft zu begrenzen. Wie wird sich das Leben in den Alpen verändern?

https://www.youtube.com/watch?v=aZ1oQlOYWc8&pp=ygUNZ2VvcmcgYmF5ZXJsZQ%3D%3D

Bayrischer Rundfunk: Muren und Sturzfluten: Orte in den Alpen kämpfen um ihre Zukunft

Überall in den Alpen bedrohen Sturzfluten, Muren und Schlammlawinen die Menschen und ihre Heimat und richten gewaltige Schäden an. Das geht nicht erst seit den dramatischen Bildern aus dem Schweizer Lötschental durch die Schlagzeilen, wo im Mai dieses Jahres das Bergdorf Blatten von einer Mure verschüttet wurde. Doch wie können sich die Orte besser schützen?

https://www.youtube.com/watch?v=nhF9D4FyjsI

Mistune 3 Wikilink Inline Parser

2025-09-20T00:00:00Z

Mistune 3 has changed its internal structure and extension mechanisms.

The Mistune advanced documentation provides several examples of how to create and register inline patterns. After a few iterations, I developed the following solution to render wikilinks:

import re  
from typing import Match  
  
from mistune import Markdown  
from mistune.core import BaseRenderer, InlineState  
from mistune.inline_parser import InlineParser  

  
def parse_wikilink(inline: "InlineParser", m: Match[str], state: "InlineState") -> int:  
    """Parse wikilink syntax [[page title]] or [[page title|display text]]."""  
    page_title = m.group('page').strip()  
    display_text = m.group('display')  
      
    # Use display text if provided; otherwise, use page title  
    if display_text is not None:  
        text = display_text.strip()  
    else:  
        text = page_title  
      
    # Create a wikilink token  
    state.append_token({  
        "type": "wikilink",  
        "children": [{"type": "text", "raw": text}],  
        "attrs": {  
            "page": page_title,  
            "display": text  
        }  
    })  
      
    return m.end()  
  
def render_wikilink_html(renderer: "BaseRenderer", children: str, page: str, display: str) -> str:  
    """Render a wikilink as an HTML anchor tag."""  
    url_page = page.replace(' ', '_')  
    return f'<a href="/wiki/{url_page}" class="wikilink">{children}</a>'  
  
def wikilink_plugin(md: "Markdown") -> None:  
    """Plugin function to add wikilink support to Mistune."""  
    # Use named groups
    WIKILINK_PATTERN = r'\[\[(?P<page>[^|\]]+)(?:\|(?P<display>[^\]]+))?\]\]'  
    md.inline.register("wikilink", WIKILINK_PATTERN, parse_wikilink, before="link")  
      
    if md.renderer and md.renderer.NAME == "html":  
        md.renderer.register("wikilink", render_wikilink_html)

To test it, you can run the following code:

from mistune import create_markdown  
    
# Create a Markdown parser with the wikilink plugin  
md = create_markdown(plugins=[wikilink_plugin])  
    
# Test examples  
text1 = "Check out [[Main Page]] for more info."  
text2 = "Visit [[Installation Guide|the installation guide]] to get started."  
text3 = "Multiple links: [[Page One]] and [[Page Two|Custom Text]]."  
    
print("Example 1:")  
print(md(text1))  
# Output: <p>Check out <a href="/wiki/Main_Page" class="wikilink">Main Page</a> for more info.</p>  
    
print("\nExample 2:")  
print(md(text2))  
# Output: <p>Visit <a href="/wiki/Installation_Guide" class="wikilink">the installation guide</a> to get started.</p>  
    
print("\nExample 3:")  
print(md(text3))  
# Output: <p>Multiple links: <a href="/wiki/Page_One" class="wikilink">Page One</a> and <a href="/wiki/Page_Two" class="wikilink">Custom Text</a>.</p>

BikeRouter and OnRouteMap

2025-09-19T00:00:00Z

Since following this year's transcontinental race and listening to the Sitzfleisch podcast by ultracycling professional Christoph Strasser and his peer Florian Kraschitzer, I became interested in long-distance cycling again. Planning long-distance cycling routes goes beyond simply connecting two points on a map. Besides finding a good route that balances distance and elevation gain, resupply is key. Food, water, and even spare parts must be planned for. Routes often require mapping out supermarkets, gas stations, or villages that can provide essential refueling points.

Bikerouter.de is an online tool for planning cycling routes with a strong focus on flexibility and detailed customization. At its core, it allows you to choose different routing profiles depending on the type of ride you are planning—whether that is road cycling, gravel, trekking, mountain biking, or simply the shortest or safest path between two points. For any route you calculate, the site can also suggest up to three alternatives, making it easy to compare different options before deciding which one fits your needs.

Routes can be built interactively by placing waypoints on the map, but you can also import existing tracks in formats like GPX, KML, or GeoJSON. Another powerful feature is the use of “no-go areas,” which can be drawn directly on the map or imported from a file; these tell the routing engine to avoid certain regions, such as busy roads or restricted trails. Once a route is ready, it can be exported in multiple formats—including GPX, FIT, CSV, and GeoJSON—or shared quickly through a shortlink or QR code.

The site does not just create routes; it also provides rich analysis. For every planned trip, Bikerouter.de shows key statistics such as distance, riding time, total ascent, maximum elevation, and a detailed elevation profile. There are even more advanced stats like “plain ascent” (which distinguishes flat from climbing sections) and energy estimates, which give a deeper understanding of how demanding the ride might be.

Behind the scenes, Bikerouter.de is powered by the BRouter routing engine with map data from OpenStreetMap and elevation data from sources like the CGIAR-CSI SRTM dataset.

OnRouteMap is a tool to plan better by finding useful stops along your route. You start by uploading a GPX file of your planned route. Once uploaded, the website identifies “points of interest” (POIs) such as supermarkets, cafés, public drinking water sources, bakeries, fast food spots, and more. Optional categories include bicycle repair shops, shelters, campsites, hotels, or other accommodations. All these are shown in proximity to the route.

On top of that, you can download the GPX file again, now enriched with the points of interest (POIs), so that you can store it on your phone for offline use.

Similar Services

The discussion in r/Ultracycling mentioned other services similar to OnRouteMap:

Using SQLite with JSON Data

2024-10-13T00:00:00Z

Using SQLite with JSON Data

SQLite does not have a native JSON column type like PostgreSQL. Instead, JSON is stored as TEXT (or sometimes BLOB), and queried or modified using SQLite’s JSON1 extension. Make sure your SQLite build includes JSON1 (for example, run: SELECT json('null');).

Key points:

Store JSON in a TEXT column.
Ensure JSON validity with json_valid().
Use JSON1 functions such as json_extract, json_set, and json_each.
You can index JSON paths using expression indexes for performance.
If you use STRICT tables (SQLite 3.37+), declaring a column as JSON enforces valid JSON automatically.

Example: Blog posts with arbitrary metadata

Table schema

CREATE TABLE blogpost (
  id        INTEGER PRIMARY KEY,
  slug      TEXT NOT NULL UNIQUE,
  title     TEXT NOT NULL,
  body      TEXT NOT NULL,
  metadata  TEXT NOT NULL DEFAULT '{}',

  -- Ensure metadata always contains valid JSON
  CHECK (json_valid(metadata))
);

The metadata column can store any structure you like: tags, SEO data, flags, analytics, experiments, etc.

Inserting data

INSERT INTO blogpost (slug, title, body, metadata)
VALUES
(
  'sqlite-json',
  'Using SQLite with JSON',
  '...',
  json('{
    "tags": ["sqlite", "json"],
    "reading_time_min": 7,
    "seo": {
      "title": "SQLite JSON Guide",
      "canonical": "https://example.com/sqlite-json"
    },
    "draft": false,
    "published_at": "2025-12-01",
    "views": 1234
  }')
),
(
  'draft-post',
  'Unreleased Ideas',
  '...',
  json('{
    "tags": ["notes"],
    "draft": true,
    "assigned_to": "alex",
    "experiments": [
      {"name": "A/B", "variant": "B"}
    ]
  }')
);

Using json('...') helps normalize the JSON and ensures validity.

Querying JSON data

Extract a single value

SELECT
  id,
  title,
  json_extract(metadata, '$.reading_time_min') AS reading_time_min
FROM blogpost;

Filter by a JSON boolean (draft posts)

SELECT id, slug, title
FROM blogpost
WHERE json_extract(metadata, '$.draft') = 1;

JSON true and false are typically returned as 1 and 0.

Query nested fields

SELECT id, slug
FROM blogpost
WHERE json_extract(metadata, '$.seo.title') LIKE '%Guide%';

Query array contents (posts tagged with `"json"`)

SELECT DISTINCT b.id, b.slug, b.title
FROM blogpost AS b
JOIN json_each(b.metadata, '$.tags') AS t
WHERE t.value = 'json';

json_each() expands a JSON array into rows.

Numeric comparisons on JSON values

SELECT
  id,
  slug,
  json_extract(metadata, '$.views') AS views
FROM blogpost
WHERE json_extract(metadata, '$.views') > 1000;

Check if a key exists

SELECT id, slug
FROM blogpost
WHERE json_type(metadata, '$.seo.canonical') IS NOT NULL;

json_type() returns NULL if the path does not exist.

Updating JSON data

Add or update a key

UPDATE blogpost
SET metadata = json_set(metadata, '$.views', 2000)
WHERE slug = 'sqlite-json';

Remove a key

UPDATE blogpost
SET metadata = json_remove(metadata, '$.assigned_to')
WHERE slug = 'draft-post';

Append a value to a JSON array

SQLite does not have a simple “append” operator, so arrays are often rebuilt explicitly:

UPDATE blogpost
SET metadata = json_set(
  metadata,
  '$.tags',
  (
    SELECT json_group_array(value)
    FROM (
      SELECT value FROM json_each(metadata, '$.tags')
      UNION ALL SELECT 'sqlite'
    )
  )
)
WHERE slug = 'draft-post';

Use UNION (instead of UNION ALL) to avoid duplicates.

Indexing JSON for performance

If you frequently query a JSON path, create an expression index:

CREATE INDEX idx_blogpost_draft
ON blogpost (json_extract(metadata, '$.draft'));

CREATE INDEX idx_blogpost_published_at
ON blogpost (json_extract(metadata, '$.published_at'));

These indexes allow SQLite to efficiently filter on JSON values.

Summary

Store JSON in a TEXT column.
Enforce validity with json_valid().
Query with json_extract, json_each, and json_type.
Update parts of JSON using json_set and json_remove.
Use expression indexes for frequently queried JSON paths.

This approach works well for flexible, evolving metadata such as blog post attributes, feature flags, or analytics data.

Further Information

The blog post SQLite JSON Virtual Columns and Indexing explains the concept of virtual columns in SQLite, which allow you to create computed columns based on JSON extraction expressions. The article also covers how to efficiently index these virtual columns for better performance when querying JSON fields in your tables, with examples demonstrating schema design, creating indexes, and writing efficient queries with SQLite's built-in JSON support. The corresponding Hacker News Discussion has more information.

You can use https://sqliteonline.com to test the examples in the browser without installing any software.

For more information, consult the SQLite JSON documentation.

Tenant Isolation in Snowflake for ML - Operational Patterns

2024-03-12T00:00:00Z

Building on the conceptual foundations my previous article Tenant Isolation in Snowflake, this follow-up explores the practical and operational realities teams face when running multi-tenant ML workloads in production. While isolation strategies are often discussed at the data-modeling or security level, ML systems introduce additional complexity: tenant-aware data copies for experimentation, safe access to customer data in lower environments, reproducible model testing, and CI/CD-style deployment pipelines spanning dev, staging, and prod.

This post focuses on hands-on patterns for operating Snowflake-backed ML platforms at scale. It covers tenant data duplication strategies, environment promotion workflows, ML experimentation with real customer data under strict controls, and operational trade-offs between cost, safety, and velocity. The goal is to provide concrete guidance for teams who already understand tenant isolation in theory and now need to make it work reliably for ML-driven products.

Recap: Tenant Isolation — From Concept to Operations

Before diving into ML-specific challenges, let’s briefly recap the main tenant isolation strategies in Snowflake, as discussed in the original post:

Strategy	Isolation Strength	Characteristics	Best For
Separate Snowflake Accounts per Tenant	Strongest	Each tenant has its own Snowflake account, users, warehouses, and data. High operational overhead.	Large/regulated customers requiring maximum security, compliance, and cost attribution
Shared Account, Separate Databases per Tenant	Strong	Each tenant gets a dedicated database within a shared account. Easier cost tracking, but some shared blast radius.	Most multi-tenant scenarios balancing isolation with operational efficiency
Shared Database, Separate Schemas per Tenant	Moderate	Each tenant has a schema in a shared database. Lower overhead, but weaker boundaries and risk of privilege mistakes.	Medium-scale deployments with trusted tenants
Shared Tables with `tenant_id` Column	Lowest	All tenants share tables, isolation enforced by row access policies and application logic. Highest scale, but weakest isolation and higher risk of data leaks.	Many small tenants where operational simplicity and scale are prioritized

Machine learning applications fundamentally differ from traditional software because their behavior is shaped jointly by code and continuously evolving data, which necessitates architectures that treat data pipelines, model lifecycle, and feedback loops as first-class, tightly integrated components rather than peripheral concerns. So ML workloads introduce new and more dynamic challenges to the architecture:

Production model monitoring and validation: In production, teams must continuously monitor, validate, and analyze ML model quality for each tenant. This requires access to up-to-date tenant data, robust logging, and the ability to attribute model performance issues to specific tenants or data segments.
ML training lifecycle: The ML lifecycle involves retraining models on fresh tenant data, evaluating new model versions, and promoting them to production. Each stage (training, evaluation, deployment) requires data access to production data, especially when rolling out models incrementally or running A/B tests.
Experimentation in lower environments: ML development is highly iterative—data scientists and engineers need to experiment with new models, features, and preprocessing pipelines in dev/staging environments. This often means working with realistic (sometimes real) tenant data, which increases the risk of data leakage and requires careful controls.
Data quality checks and remediation: Data quality issues are often detected in production, but fixes and validation must be applied in lower environments first. This workflow requires safe, auditable ways to copy, mask, or anonymize tenant data for debugging and remediation without violating isolation boundaries.
Reproducibility: ML pipelines need consistent, isolated snapshots of data and code.
Automation & cost: Frequent cloning, cleanup, and environment promotion can drive up costs and require robust automation.
Compliance: ML experiments may touch sensitive data, raising the bar for auditability and blast-radius reduction.

The rest of this article explores how to adapt and extend the isolation patterns to meet the operational realities of multi-tenant ML platforms.

Environment Topology for Multi-Tenant ML Systems

A typical environment structure maps to the standard dev, staging, and prod environments and applies extra requiements on how you segment tenants to achive safety, velocity, and managable operational complexity:

Development: For rapid iteration, experimentation, and debugging. Data scientists and engineers need flexibility. Guardrails are put in place (technically and operationally) that no sensitive/customer data must be used in the development environments to prevent accidental data leaks. All ML development in this environment must only use anonymized or synthetical data.
Staging: A pre-production environment for integration testing, model validation, and data quality checks using production-like data. Staging is where you catch issues before they impact customers. It should be possible to copy data from a production tenant to a staging tenant in a controlled way to validate ML Model behaviour.
Production: The live environment serving real tenant workloads, where safety, auditability, and performance are paramount.

There are two main patterns for mapping environments in Snowflake:

Account-per-Environment: Each environment (dev, staging, prod) gets its own Snowflake account. This provides the strongest isolation—no risk of accidental cross-environment data access, and clear separation of roles, warehouses, and billing. However, it increases operational overhead and complicates automation and cross-environment analytics. Tenenat/Data copies between accounts become more complex and you cannot benefit from Snowflake zero copy cloning capabilities.
Database-per-Environment: All environments live in a single Snowflake account, separated by databases(e.g., myapp_dev, myapp_staging, myapp_prod). This reduces cost and simplifies automation, but increases the risk of accidental data access across environments and requires stricter RBAC and naming conventions.

The challenge multiplies when you add tenants. For each environment, you must decide how to isolate tenants:

Account-per-tenant-per-environment: Maximum isolation, but operationally heavy and rarely justified except for the largest, most regulated customers.
Database-per-tenant-per-environment: A common compromise—each tenant gets a database in each environment. This enables per-tenant backup, restore, and lifecycle management, but can lead to database sprawl as the number of tenants grows.

Tenant Data Copy Strategies in Practice

Effective data copy strategies are essential for enabling safe ML experimentation, model retraining, and debugging in multi-tenant Snowflake environments. The design needs to balance complexity, speed, cost, and risk—especially when working with sensitive or large-scale tenant data.

Zero-Copy Cloning for Tenant-Scoped Datasets

Snowflake’s zero-copy cloning is a powerful feature for ML workflows. It allows you to instantly create a snapshot of a database, schema, or table for a tenant—without duplicating storage. This is ideal for:

Creating isolated dev/staging environments for a tenant
Running experiments or model training on a consistent data snapshot
Debugging production issues with a point-in-time copy

Full vs. Partial Tenant Copies (Time-Bounded, Feature-Bounded)

Not all ML use cases require a full copy of tenant data. There are two main ways to reduce data sizes:

Time-bounded copies: Only clone recent data (e.g., last 30 days) to reduce storage and speed up experimentation.
Feature-bounded copies: Copy only the columns/features needed for a specific ML task, masking or omitting sensitive fields.

Cloning of the input data vs. storing the output of the feature pipeline

When ML development does not include feature development, it might be sufficient to store the columns/features generated by the data pipeline that is used as the input for the ML model. A robust metadata management and/or feature store will help to track data lineage. It is necessary to also put controls in place for derived data to never leave a tenant context.

Cost Visibility and Cleanup Automation

Frequent cloning and data copying can quickly lead to unexpected storage costs. Best practices:

Tag all clones and copies with metadata (tenant, environment, purpose, expiration)
Automate cleanup of temporary datasets after experiments or model validation
Monitor storage usage and set alerts for orphaned or stale clones

ML Experimentation and Data Cloning

Experimentation is at the heart of ML development. An operational pattern for multi-tenant ML systems is maintaining point-in-time (PIT) snapshots of production tenant data in staging environments for continuous model validation. This approach decouples model development from KPI evaluation, ensuring that performance metrics reflect true model improvements rather than data drift or quality issues.

The Challenge: Data Drift vs. Model Drift

When validating ML models, you need to distinguish whether performance changes are due to:

Model improvements/regressions: Changes in model code or training
Data drift: Evolving customer behavior or data quality issues
Infrastructure changes: Schema updates, feature pipeline bugs

Without stable reference datasets, KPI monitoring becomes unreliable and debugging is difficult. The Solution is regular PIT Snapshots with Fixed Validation Sets.

Use Snowflake's zero-copy cloning to create dated snapshots of production tenant data in staging and keep them as Immutable Validation Sets: Each snapshot remains frozen. New models are evaluated against the same historical data, making results comparable over time.

Automated KPI Computation: Run standardized validation queries against each snapshot to compute metrics (accuracy, precision, RMSE, etc.) for every model version.

Snapshot Rotation: Keep the last N snapshots (e.g., 4-8 weeks) to track model performance trends, then archive or drop older snapshots to control costs.

This pattern also helps detect and isolate data quality problems:

If a model's KPIs drop on a new snapshot but remain stable on older ones, suspect data drift or pipeline bugs—not model regression.
If KPIs degrade across all snapshots, the model itself likely has issues.

Cost and Storage Management

Snapshots consume storage incrementally (only changed data), but can accumulate. Best practices is to set retention policies (e.g., keep 8 weeks, archive to cheaper storage after 90 days) and use Snowflake's UNDROP and Time Travel as fallbacks instead of keeping every daily snapshot.

Deployment Pipelines: From Dev to Prod

Robust deployment pipelines are essential for safely and efficiently moving ML models, features, and data transformations from development to production in multi-tenant Snowflake environments. These pipelines must account for both code and data, and support rapid iteration while minimizing risk.

CI/CD Concepts for Data and Models

The core ML deployment pattern is to treat data pipelines, feature engineering code, and model artifacts as first-class citizens in CI/CD workflows:

Use version control for all code, configuration, and schema definitions.
Automate testing of data pipelines and model training in dev/staging before production promotion.
Integrate model validation and data quality checks as pipeline steps, not afterthoughts.
Use tools like MLFlow to track metadata, KPIs metrics and artefacts generated during model evaluation. This can include reports, learned model weights and metadata for data snaphots.

Promoting Schemas, Features, and Models Across Environments

Promotion should be automated and auditable:

Use migration tools or versioned DDL to apply schema changes consistently across dev, staging, and prod.
Promote feature definitions and model artifacts only after passing validation on production-like data in staging.
Tag and track all promoted objects with environment, version, and deployment metadata.

Environment-Specific Snowflake Objects

Each environment may require different Snowflake resources:

Warehouses: Size and configure compute resources to match environment needs (e.g., smaller in dev, larger in prod).
Roles and RBAC: Restrict access in lower environments, and enforce least-privilege in production.
Tasks and Streams: Automate data ingestion, transformation, and model scoring with environment-specific schedules and parameters.

Rollback Strategies for Multi-Tenant Deployments

Failures are inevitable—robust rollback is critical:

Use zero-copy clones and Time Travel to quickly revert schemas or data to a known good state.
For model rollouts, support canary or phased deployments (e.g., enable new model for a subset of tenants, monitor KPIs, then expand rollout).
Maintain previous model versions and feature definitions for rapid rollback if regressions are detected.

By treating data, features, and models as deployable artifacts, and automating their promotion and rollback, teams can achieve both agility and safety in multi-tenant ML operations on Snowflake.

Operational Trade-Offs and Lessons Learned

Where Teams Over-Engineer

Overly granular isolation (e.g., every tenant in its own account/environment) creates a maintenance burden that rarely pays off except for the largest or most regulated customers.
Excessive manual controls and approval steps slow down experimentation and deployment, leading to bottlenecks and frustrated teams. Data Scientists need access to the data, rather then locking away the production data make sure experiments are run in a controlled/automated fashion.

Where Teams Underestimate Risk

Under-investing in RBAC, audit logging, and automated data cleanup can lead to costly data leaks or compliance violations.
Failing to automate environment and tenant provisioning results in configuration drift and inconsistent access boundaries.
Ignoring cost monitoring for clones, snapshots, and unused resources can cause runaway storage bills.

What to Automate Early

Environment and tenant provisioning (infrastructure-as-code, templates)
Data copy/clone tagging, expiration, and cleanup. Expose the capabilities throuhg APIs or CI/CD pipelines
Schema migrations and model promotion pipelines
RBAC policy enforcement and regular audits
Cost monitoring and alerting for storage and compute

The most successful teams revisit their architecture and automation regularly, adapting as scale and requirements evolve. Start simple, automate aggressively, and be ready to tighten controls as your platform and customer base grow.

Closing Thoughts

Tenant isolation in Snowflake for ML is not a one-time architectural decision, but an ongoing operational discipline. As ML platforms scale, the interplay between data, code, and tenant boundaries becomes more complex—and more critical to get right.

Key Takeaways:

There is no single “best” isolation model; the right approach evolves with your product, customer base, and regulatory landscape.
Automation, tagging, and regular audits are essential to keep environments, data copies, and access controls manageable at scale.
ML workloads amplify the risks and operational challenges of multi-tenancy, making reproducibility, rollback, and monitoring non-negotiable.

Looking Forward:

Expect the boundaries between data engineering, ML, and platform operations to blur further as teams adopt more advanced automation and governance.
New Snowflake features (e.g., object tagging, masking policies, data clean rooms) will continue to expand the toolkit for safe, scalable multi-tenant ML.
The most resilient teams treat tenant isolation as a living process—reviewing, testing, and evolving their patterns as both technology and business needs change.

Tenant isolation is a journey, not a destination. By combining strong technical controls with a culture of continuous improvement, teams can deliver both agility and safety for ML-driven products on Snowflake.

Exploring Mountain Huts with SPARQL and Wikidata

2023-12-23T00:00:00Z

For outdoor enthusiasts and avid hikers, searching for mountain huts or shelters is common when planning tours. In this blog post, we will retrieve information about mountain huts around a specific latitude and longitude using the powerful combination of SPARQL and Wikidata.

Understanding SPARQL

SPARQL (SPARQL Protocol and RDF Query Language) is a query language designed for querying data stored in Resource Description Framework (RDF) format. RDF provides a standard way to represent information, making it an ideal choice for querying diverse datasets.

Accessing Wikidata:

Wikidata, a collaborative knowledge base, hosts a wealth of information on various topics, including geographical features like mountain huts. By running SPARQL queries on the Wikidata platform, we can extract specific details about these huts based on their geographic coordinates.

Retrieving Mountain Huts:

Let’s look at a SPARQL query to retrieve information about mountain huts around a given latitude and longitude. The following query can be used as a starting point:

SELECT DISTINCT ?distance ?place ?placeLabel ?lat ?long ?elevation WHERE {
  SERVICE wikibase:around {
    # Items with coordinate location (P625)
    ?place wdt:P625 ?location .
    # Circle with a center point in WKT (longitude latitude)
    bd:serviceParam wikibase:center "Point(8.114444 46.521944)"^^geo:wktLiteral .
    # Circle radius in km
    bd:serviceParam wikibase:radius "10" .
    bd:serviceParam wikibase:distance ?distance .
  }

  ?place p:P625 ?coordinates .
  ?coordinates psv:P625 [
    wikibase:geoLatitude ?lat ;
    wikibase:geoLongitude ?long
  ] .

  # Instance of: bivouac shelter (Q879208) or mountain hut (Q182676)
  ?place wdt:P31 ?subclassOf .
  VALUES ?subclassOf { wd:Q879208 wd:Q182676 } .

  # Labels with fallback languages
  SERVICE wikibase:label { bd:serviceParam wikibase:language "de,gsw,en,fr,it" . }

  OPTIONAL { ?place wdt:P2044 ?elevation . }
}
ORDER BY ?distance

Replace the numeric values in the WKT literal Point(longitude latitude) with the desired coordinates. This query retrieves mountain huts within a specified radius (in this example, 10 kilometers) of the given location.

You can also search around a Wikidata location by using its Wikidata ID (e.g., Q68103 for Interlaken) as a reference:

wd:Q68103 wdt:P625 ?mainLoc .
# Use the around service
SERVICE wikibase:around {
  # Items with coordinate location (P625)
  ?place wdt:P625 ?location .
  # Circle with ?mainLoc as the center (the coordinate location)
  bd:serviceParam wikibase:center ?mainLoc .
  # Circle radius in km
  bd:serviceParam wikibase:radius "40" .
}

To try it out, just copy and paste the example into https://query.wikidata.org

You can use the Python library SPARQLWrapper to retrieve the results via an API in JSON format:

from SPARQLWrapper import SPARQLWrapper, JSON
import json

query = '''
SELECT DISTINCT ?distance ?place ?placeLabel ?lat ?long ?elevation WHERE {
  SERVICE wikibase:around {
    ?place wdt:P625 ?location .
    bd:serviceParam wikibase:center "Point(8.114444 46.521944)"^^geo:wktLiteral .
    bd:serviceParam wikibase:radius "10" .
    bd:serviceParam wikibase:distance ?distance .
  }
  ?place p:P625 ?coordinates .
  ?coordinates psv:P625 [
    wikibase:geoLatitude ?lat ;
    wikibase:geoLongitude ?long
  ] .
  ?place wdt:P31 ?subclassOf .
  VALUES ?subclassOf { wd:Q879208 wd:Q182676 } .
  SERVICE wikibase:label { bd:serviceParam wikibase:language "de,gsw,en,fr,it" . }
  OPTIONAL { ?place wdt:P2044 ?elevation . }
}
ORDER BY ?distance
'''

user_agent = "python test"
endpoint_url = "https://query.wikidata.org/sparql"
sparql = SPARQLWrapper(endpoint_url, agent=user_agent)
sparql.setQuery(query)
sparql.setReturnFormat(JSON)
result = sparql.queryAndConvert()['results']['bindings']
print(json.dumps(result, indent=4))

Tenant Isolation in Snowflake

2023-10-16T00:00:00Z

Multi-tenancy is an architectural approach in which a single software system or data platform serves multiple independent customers (tenants), while ensuring that each tenant’s data, workloads, and configurations remain logically or physically isolated according to defined boundaries. The goal of multi-tenancy is to maximize resource efficiency and operational scalability while preserving security, performance predictability, and administrative separation, with isolation implemented at one or more layers such as infrastructure, accounts, databases, schemas, or rows within shared tables.

There is no single best architecture and it is always a balance between competing goals, architectural choices, customer size, and the total number of customers being served. This post walks through the main tenant isolation strategies in Snowflake—from fully separate accounts down to logical isolation with a tenant_id column—covering pros, cons, best practices, and operational considerations.

This article focuses primarily on tenant isolation from a data storage and data access perspective, examining how tenants can be separated using accounts, databases, schemas, or shared tables. It is important to note, however, that Snowflake introduces a separate and equally important dimension through its compute layer, where virtual warehouses provide independent scaling, workload isolation, and performance control. While storage-level isolation defines how data is organized and secured, compute-level isolation plays a critical role in managing concurrency, cost, and noisy-neighbor effects.

What Do We Mean by Tenant Isolation?

Tenant isolation typically aims to achieve some combination of:

Security isolation – preventing data leakage across tenants
Performance isolation – avoiding noisy-neighbor effects
Operational independence – deploying changes or fixes per tenant
Cost visibility – attributing usage to tenants
Scalability – onboarding and offboarding tenants efficiently

Snowflake’s architecture (separate storage and compute, strong RBAC, and secure sharing) allows you to choose isolation at multiple layers.

Option 1: Separate Snowflake Accounts per Tenant

Tenant isolation using separate Snowflake accounts is best suited for large enterprise customers and for scenarios with strict compliance or regulatory requirements where strong isolation is mandatory. It is also appropriate for tenants with highly variable or unpredictable workloads, as well as for “bring your own Snowflake” models where customers operate within their own Snowflake environments.

Description

Each tenant gets its own Snowflake account. Data, users, warehouses, and security policies are completely isolated.

Tenant A → Snowflake Account A  
Tenant B → Snowflake Account B

Best Practices

Snowflake Organizations should be used to centrally manage and govern multiple Snowflake accounts, providing a unified view for administration, security, and billing across tenants. This helps reduce operational overhead while maintaining strong account-level isolation.

Account and tenant provisioning should be fully automated using infrastructure-as-code tools such as Terraform or Snowflake’s APIs. Automation ensures consistency, reduces manual errors, and makes onboarding and offboarding tenants predictable and repeatable at scale.

Role definitions, warehouse configurations, and database naming conventions should be standardized across all tenants. Consistent patterns simplify access management, monitoring, and troubleshooting, and they make it significantly easier to apply changes or enforce policies uniformly.

When cross-tenant or centralized analytics is required, Snowflake’s secure data sharing capabilities should be used instead of copying data between accounts. Secure sharing enables controlled access to tenant data while preserving isolation and minimizing data duplication.

Pros

Strongest isolation (security and blast radius)
Clear cost attribution per tenant
Independent upgrades and experiments
Regulatory friendly (data residency, compliance)

Cons

High operational overhead
- Account provisioning
- User and role management
- Monitoring and alerting per account
Harder cross-tenant analytics
More complex CI/CD
Potentially higher cost for small tenants

Option 2: Shared Account, Separate Databases per Tenant

A shared account with separate databases per tenant is well suited for a medium number of tenants with moderate compliance requirements. This approach is particularly useful when per-tenant backup, restore, or data lifecycle operations need to be handled independently without the overhead of multiple accounts.

Description

All tenants live in one Snowflake account, but each tenant gets its own database.

ACCOUNT
 ├── TENANT_A_DB
 ├── TENANT_B_DB

Best Practices

Each tenant should be assigned its own database while maintaining an identical schema structure across all tenant databases. This consistency simplifies development, testing, and operations, and allows changes to be applied predictably across tenants.

Database roles should be used to control tenant access at the database level. Leveraging database roles provides clear separation of privileges, reduces the risk of misconfiguration, and aligns well with Snowflake’s role-based access control model.

Databases should be tagged with metadata such as tenant, environment, and cost_center to support cost tracking, governance, and operational visibility. Tags make it easier to analyze usage, implement chargeback or showback models, and apply policies consistently.

Schema migrations should be fully automated across all tenant databases using standardized deployment pipelines or migration tools. Automation ensures schema changes are applied reliably and uniformly, minimizing drift and reducing the operational burden as the number of tenants grows.

Pros

Strong logical isolation
Easier to manage than multiple accounts
Database-level privileges are simple and explicit
Easier cost tracking using database tags and query history

Cons

Still some shared blast radius
Schema migrations must be coordinated across databases
Large numbers of tenants can lead to database sprawl

Option 3: Shared Database, Separate Schemas per Tenant

Tenant isolation using a share databases with schema separation per Tenant within a single Snowflake account is well suited for smaller tenants and internal multi-team environments where strong logical separation is needed without the overhead of multiple accounts. It is also a good fit for early-stage SaaS platforms that want to balance isolation, simplicity, and operational efficiency while they scale.

Description

A single database hosts multiple schemas, one per tenant.

DATABASE
 ├── TENANT_A_SCHEMA
 ├── TENANT_B_SCHEMA

Best Practices

Strict role-to-schema mappings should be enforced so that each role has access only to the schemas it is explicitly responsible for. This minimizes the risk of accidental data exposure and makes access boundaries clear and auditable.

Cross-schema references should be avoided wherever possible, as they weaken isolation guarantees and make it harder to reason about data ownership and access paths. Keeping schemas self-contained improves security, maintainability, and portability.

Consistent naming conventions for schemas, roles, and objects should be used across all tenants. Standardization simplifies automation, monitoring, and troubleshooting, and reduces cognitive overhead for operators and developers.

Grants and permissions should be periodically audited to ensure they still reflect intended access patterns. Regular reviews help detect privilege creep, misconfigurations, and potential security gaps before they become issues.

Pros

Fewer objects to manage than databases
Faster onboarding of new tenants
Simple to share common reference tables
Lower operational overhead

Cons

Weaker isolation than databases
Schema-level privilege mistakes can cause data exposure
Schema explosion with many tenants
Harder to enforce per-tenant performance limits

Option 4: Shared Tables with `tenant_id` Column

This approach is well suited for environments with a large number of small tenants and primarily read-heavy analytics workloads, where sharing infrastructure provides significant efficiency gains. It allows the platform to scale to many customers without excessive operational overhead.

Because isolation is largely enforced logically, it works best when strong application-level controls are in place to prevent cross-tenant access and enforce correct query patterns. It is also an attractive option for cost-sensitive environments, as shared storage and compute help minimize overall platform expenses.

Description

All tenants share the same tables, distinguished by a tenant_id column.

SELECT *
FROM orders
WHERE tenant_id = 'tenant_123';

Isolation is enforced through application logic and Snowflake features such as row access policies.

Best Practices

Access to shared tables should be enforced using row access policies to ensure that each tenant can only see its own data, regardless of how queries are written. This provides a critical safety net and reduces reliance on application logic alone for isolation.

The tenant_id should always be included in primary keys and used consistently in table design, as this makes tenant boundaries explicit and prevents accidental key collisions. Including tenant_id also enables more efficient pruning and predictable query behavior.

Clustering tables by tenant_id should be considered, especially when tenants frequently query their own data in isolation. Proper clustering can significantly improve query performance and reduce unnecessary data scanning in large shared tables.

Automated tests should be added to validate that all queries include the appropriate tenant filters and that row access policies are correctly applied. Testing helps catch regressions early and prevents subtle mistakes from leading to cross-tenant data exposure.

Finally, query patterns should be continuously monitored to detect any signs of cross-tenant access or anomalous behavior. Regular analysis of query and access logs helps identify misconfigurations, misuse, or potential security issues before they escalate.

Pros

Lowest operational overhead
Easy schema evolution
Excellent for analytics across tenants
Efficient storage usage

Cons

Weakest isolation
Higher risk of data leaks
Requires disciplined query patterns
Harder to delete or export a single tenant’s data
Performance contention between tenants

Operational Considerations Across All Models

1. Cost Management

Use resource monitors at warehouse or account level
Tag warehouses, databases, or queries with tenant metadata
Periodically review QUERY_HISTORY and WAREHOUSE_METERING_HISTORY

2. Performance Isolation

Separate warehouses for:
- ETL
- Customer queries
- Internal analytics
Size warehouses based on tenant tier
Consider multi-cluster warehouses for concurrency spikes

3. Security and Auditing

Follow least-privilege RBAC
Regularly audit grants (SHOW GRANTS)
Enable access history and query logging
Consider masking policies for PII

4. Data Lifecycle Management

Define per-tenant retention and purge policies
Automate tenant offboarding
Plan for per-tenant export or deletion early

5. CI/CD and Schema Changes

Treat schemas as code
Use migration tools or versioned DDL
Test changes against multiple tenants
Avoid manual schema drift

Choosing the Right Model

Requirement	Recommended Approach
Maximum isolation	Separate accounts
Strong isolation, fewer ops	Database per tenant
Moderate isolation	Schema per tenant
High scale, low cost	Shared tables with `tenant_id`

In practice, you often implement hybrid approaches where one or more customers are grouped within a single Snowflake account, while each customer is isolated using a dedicated database. This model strikes a balance between strong logical isolation and manageable operational overhead, allowing teams to scale without fully committing to an account-per-tenant strategy.

This pattern is often aligned with a cell-based architecture, where each account represents a cell that hosts a bounded set of customers with similar characteristics, such as region, compliance profile, or service tier. Within a cell, customers are isolated at the database level, while additional cells can be added over time to limit blast radius, control growth, and support horizontal scaling. This approach enables predictable operations, clearer governance boundaries, and a gradual path toward stronger isolation for customers that outgrow their current cell.

Additional Documentation

Snowflake Architecture Overview
Foundational reading for understanding why different isolation models behave the way they do.
https://docs.snowflake.com/en/user-guide/intro-key-concepts
Best Practices for Designing Snowflake Databases
Covers logical separation, schema organization, and object management.
https://docs.snowflake.com/en/user-guide/db-design
Snowflake Multi-Account Strategy (Organizations)
Essential for account-per-tenant designs.
https://docs.snowflake.com/en/user-guide/organizations
Building SaaS Applications on Snowflake (Whitepaper)
One of the best high-level discussions of tenant isolation patterns.
https://www.snowflake.com/resource/building-saas-applications-on-snowflake/
Microsoft: Multi-Tenant SaaS Database Patterns
Excellent conceptual grounding; applies cleanly to Snowflake.
https://learn.microsoft.com/en-us/azure/architecture/guide/multitenant/overview
AWS SaaS Tenant Isolation Strategies
Useful framework for evaluating isolation strength, regardless of platform.
https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/tenant-isolation.html

Blue Yonder at PyCon.DE 2023

2023-04-25T00:00:00Z

Blue Yonder History

It has now been 10 years since Blue Yonder started its first sponsorship of a Python conference at EuroPython in Florence. Since then, we have been sponsoring or organizing at least one Python event per year. For me, this has always been part of my mission: to convince leadership and fellow team leads that participating in the open-source community benefits employee development and overall corporate culture. Young engineers learn to represent the company and connect with other open-source developers.

This year, PyCon.DE was hosted in Berlin. With 1,500 attendees, the conference has grown tremendously over the past years. The Berlin Congress Center is, of course, a very professional venue, and the organizing committee did an excellent job running a smooth conference overall. Still, I hope that PyCon.de will be hosted in another city next year (maybe even in Switzerland or Austria). Leipzig, Frankfurt, Hamburg, Basel, Bern, or Wien would be great locations for 2024.

Cyclic Boosting

The main topic of this year's Blue Yonder conference booth was the open-sourcing of Cyclic Boosting. Cyclic Boosting has been Blue Yonder’s core ML algorithm for many years. Felix Wick gave a talk about exploring the power of Cyclic Boosting: a pure-Python, explainable, and efficient ML method

We also hosted a small Kaggle ML/Retail Challenge where the open-source community can apply their ML algorithms to a typical retail problem and benchmark them against a baseline Cyclic Boosting model.

The challenge is to accurately forecast demand for 300 retail products across 20 retail stores. Accurate demand forecasting is crucial for retailers because it enables informed decisions regarding inventory management, pricing strategies, and sales projections, all of which can significantly impact the bottom line. In short, demand forecasting is essential for retailers aiming to optimize operations and maximize profits to stay competitive in a crowded retail landscape.

It was quite fun to discuss solutions and technical approaches at our booth, and people were highly engaged, trying to beat Felix’s reference implementation.

Notable PyCon.DE talks

Wald: A Modern and Sustainable Analytics Stack from Florian Wilhelm.

The name WALD stack comes from the four technologies it is composed of, i.e., a cloud data warehouse such as Snowflake or Google BigQuery, the open-source data integration engine Airbyte, the open-source full-stack BI platform Lightdash, and the open-source data transformation tool dbt.

Pragmatic ways of using Rust in your data project from Christopher Prohm

Writing efficient data pipelines in Python can be tricky. The standard recommendation is to use vectorized functions implemented in NumPy, pandas, or similar libraries. However, what do you do when the processing task does not fit these libraries? Using plain Python can result in poor performance, particularly when handling large datasets.

Actionable Machine Learning in the Browser with PyScript from Valero Maggio

PyScript brings the full PyData stack to the browser, opening up unprecedented use cases for interactive, data-intensive applications. In this scenario, the web browser becomes a ubiquitous computing platform, operating within a (nearly) zero-installation and serverless environment.

Hiring

We are hiring new talent for our AI/ML teams at Blue Yonder. If you are interested in one of the following positions—Senior Machine Learning Engineer, Senior Data Engineer, or Full-Stack Developer—just reach out to me.

Peter Hoffmann

Garmin inReach Mini 2 Leaflet checkin map

Plans

Messaging

Build your own Tracking with Check-In Messages

Local macOS Dev Setup: dnsmasq + caddy-snake for python projects

dnsmasq on macOS Sonoma (Local DNS with .lan)

1. Install dnsmasq

2. Configure dnsmasq

3. Tell macOS to use dnsmasq

Option A: System Settings (GUI)

Option B: Command line

4. Start dnsmasq

5. Flush DNS cache

6. Test

Result

Caddy

Caddyfile: host multiple WSGI services

Update

Georg Bayerle - Der Alpen Appell

Weiterführendes Material

Mistune 3 Wikilink Inline Parser

BikeRouter and OnRouteMap

Similar Services

Using SQLite with JSON Data

Using SQLite with JSON Data

Example: Blog posts with arbitrary metadata

Table schema

Inserting data

Querying JSON data

Extract a single value

Filter by a JSON boolean (draft posts)

Query nested fields

Query array contents (posts tagged with "json")

Numeric comparisons on JSON values

Check if a key exists

Updating JSON data

Add or update a key

Remove a key

Append a value to a JSON array

Indexing JSON for performance

Summary

Further Information

Tenant Isolation in Snowflake for ML - Operational Patterns

Recap: Tenant Isolation — From Concept to Operations

Environment Topology for Multi-Tenant ML Systems

Tenant Data Copy Strategies in Practice

ML Experimentation and Data Cloning

Deployment Pipelines: From Dev to Prod

Operational Trade-Offs and Lessons Learned

Closing Thoughts

Exploring Mountain Huts with SPARQL and Wikidata

Understanding SPARQL

Accessing Wikidata:

Retrieving Mountain Huts:

Tenant Isolation in Snowflake

What Do We Mean by Tenant Isolation?

Option 1: Separate Snowflake Accounts per Tenant

Description

Best Practices

Pros

Cons

Option 2: Shared Account, Separate Databases per Tenant

Description

Best Practices

Pros

Cons

Option 3: Shared Database, Separate Schemas per Tenant

Description

Best Practices

Pros

Cons

Option 4: Shared Tables with tenant_id Column

Description

Best Practices

Pros

Cons

Operational Considerations Across All Models

1. Cost Management

2. Performance Isolation

dnsmasq on macOS Sonoma (Local DNS with `.lan`)

Query array contents (posts tagged with `"json"`)

Option 4: Shared Tables with `tenant_id` Column