PLV8 for PostgreSQL and CIDR for all

We've been making some small, but significant, enhancements to your database experience at Compose, so we thought now would be a good time to introduce you to the two latest; a newly supported language extension for PostgreSQL and the ability to be more expressive when setting up TCP Whitelists to control your database access.

PLV8 now available for PostgreSQL deployments

New deployments of PostgreSQL will be arriving with the capability to run JavaScript as an internal language. Earlier this year, we enabled Perl as a trusted PostgreSQL language. By enabling PLV8, users will be able to choose which – Perl or JavaScript – is more appropriate to their application needs. Actually, PLV8 enables three languages; classic JavaScript, the Ruby-esque CoffeeScript and the follow-up to CoffeeScript, LiveScript. We'll be focussing on the JavaScript element here.

There's a lot you can do with PLV8. The PostgreSQL CREATE FUNCTION is used to create JavaScript functions. The integration runs a lot deeper though. Functions can return sets of data to PostgreSQL or handle triggers firing with JavaScript code. The can also run database queries including prepared statements and execute sub-transactions when you need atomic properties. This is all topped off with the ability to log events and errors, tidy or quote returned values and a whole set of type coercion rules to make it easier to move data between PostgreSQL and the JavaScript code. It's too much to cover here but the extension documentation covers much of it and we'll be having a deep dive into its options in the near future.

Existing users will need to drop a mail to support@compose.io to get PLV8 enabled on their PostgreSQL deployments.

CIDR ranges for all TCP whitelists

When we introduced TCP whitelists to Elasticsearch, RethinkDB and Redis and, since then, to PostgreSQL and the beta MongoDB+, we allowed users to add single IP addresses to the whitelist. That's all changed now, as we are introducing CIDR block notation to our access portals.

The original assumption was that only particular machines on the Internet would need to be cleared. Well, customers showed us that there were a number of use cases where a range of IP addresses may need to be granted access. With that in mind, we've added the intelligence to the portal to match with CIDR block notation. A CIDR block notation address looks like an IP address followed by a slash and a number from 8 to 32.

The number says how many bits of the preceding address are significant for matching. So 192.168.1.0/24 means the first 24 bits are significant. With each octet of the address being 8 bits, 24 bits means the 192, 168 and 1 are significant so 192.168.1 is matched. The last octet can be any of the 255 values available when being matched against and so the CIDR block notation represents the IP addresses 192.168.1.0 to 192.168.1.255.

If no "/" is given in an address, we'll assume that all the bits in the address are significant and give it the "/32" postfix. This means that if you enter 192.168.200.100, then that will be displayed as 192.168.200.100/32. Every bit must match with a /32. You can also make bigger ranges such as 192.168.0.0/16, where any IP address beginning with 192.168 is included. Finally, you can also focus in on much smaller ranges, such as 192.168.111.48/28, which would match the range from 192.168.111.48 to 192.168.111.63. There are calculators available on the web to help you work out what ranges you need.

In practice, it all means that you can define ranges of IP addresses, rather than just single IP addresses, in Compose access portals, making it easier and quicker to control who accesses your database.