Building maps that use dynamic tiles from the database is a lot of fun: you get the freshest data, you don't have to think about generating a static tile set, and you can do it with very minimal middleware, using pg_tileserv.

However, the day comes when it's time to move your application from development to production, what kinds of things should you be thinking about?

Let's start with load

While every year feels like the year of Postgres these days, 2012 did not. For most observers, 2012 was the year of "Big Data" as NoSQL technologies like Hadoop and MongoDB were demonstrating powerful new data management use cases.

At the same time, Crunchy Data was still just an idea and was beginning to engage with various consumers of database technology on how this wave of new open source tools were impacting their data strategy. During these early discussions - and many since - we heard how organizations were building a modern data management toolbox. The tools were being selected to support the next generation of application development. Organizations were including a NoSQL tool like Hadoop, one or two legacy databases, a data caching or message broker technology, and a modern relational tool as the new SQL standard. And the relational database tool of choice that we heard about time and time again, was Postgres

Greetings friends! We have come to our final blog post in my series about the data science workflow using PostgreSQL. In the last blog post, we used PL/R to create a function which returns the output from a logistic regression model trained on our fire data. We then took that model object and stored it into a separate table.

Today we are going to finish up by showing how to use that stored model to make predictions on new data. By the way, I did all of the Postgres work for the entire blog series in Crunchy Bridge.

Crunchy Data is pleased to announce the publication of the Crunchy Data PostgreSQL Security Technical Implementation Guide (STIG) by the United States Defense Information Systems Agency (DISA

This new guide is the result of ongoing collaboration with DISA and provides security guidance for PostgreSQL 9.6 through 12

Charleston, S.C. (January 6, 2021) - Crunchy Data — the leading provider of trusted open source PostgreSQL — is pleased to announce the release of the Crunchy Data PostgreSQL Security Technical Implementation Guide

Greetings friends! We have finally come to the point in the Postgres for Data Science series where we are not doing data preparation. Today we are going to do modeling and prediction of fire occurrence given weather parameters… IN OUR DATABASE!

Quick recap:

1. We found some data

There are a lot of ways to load data into a PostgreSQL/PostGIS database and it's no different with spatial data. If you're new to PostGIS, you've come to the right place. In this blog post, I'll outline a few free, open source tools you can use for your spatial data import needs.

You can use a desktop GUI application like QGIS, and/or command-line utilities. If you want more flexibility, it's great to have both types in your toolkit.

I'll talk about importing to PostGIS within the context of vector data, since it's a much more common use case. It's possible to import raster data

Some people are obsessed with sports or cars. I follow computer hardware. The PC industry has overclocking instead of nitrous, plexi cases instead of chrome, and RGB lighting as its spinning wheels.

The core challenge I enjoy is cascading small improvements to see if I can move a bottleneck. The individual improvements are often just a few percent. Percentage gains can compound as you chain them together.

Today I'm changing the memory speed on my main test system, going from 2133MHz to 3200MHz, and measuring how that impacts PostgreSQL SELECT results. I'm seeing a 3% gain on this server, but as always with databases that's only on a narrow set of in-memory use cases. Preview:

Why more benchmarks?

In this series so far we've talked about how to get our Django application to save uploaded images as bytea in Postgres. We've also walked through an example of a PL/Python function that processes the binary data to apply a blur filter to the uploaded image. Now, we'll show how to retrieve the blurred image from Django.

Use the function in a SQL view mapped to a Django model

Now that we have a PL/Python function, what do we do with it? The function lives in PostgreSQL, so we'll have to figure out how to call the function from Django.

You do have the option in Django to perform raw SQL queries

I recently wrote about building a Django app that stores uploaded image files in bytea format in PostgreSQL. For the second post in this series, we're now going to take a look at applying a blur filter to the uploaded image using PL/Python